[jira] [Created] (HBASE-15340) Partial row result of scan may return data violates the row-level transaction
Jianwei Cui created HBASE-15340:
---
Summary: Partial row result of scan may return data violates the
row-level transaction
Key: HBASE-15340
URL: https://issues.apache.org/jira/browse/HBASE-15340
Project: HBase
Issue Type: Bug
Components: Scanners, Transactions/MVCC
Affects Versions: 2.0.0
Reporter: Jianwei Cui
There are cases the region sever will return partial row result, such as the
client set batch for scan or configured size limit reached. In these
situations, the client may return data that violates the row-level transaction
to the application. The following steps show the problem:
{code}
// assume there is a test table 'test_table' with one family 'F' and one region
'region'.
// meanwhile there are two region servers 'rsA' and 'rsB'.
1. Let 'region' firstly located in 'rsA' and put one row with two columns 'c1'
and 'c2' as:
> put 'test_table', 'row', 'F:c1', 'value1', 'F:c2', 'value1'
2. Start a client to scan 'test_table', with scan.setBatch(1) and
scan.setCaching(1). The client will get one column as : {column='F:c1' and
value='value1'} in the first rpc call after scanner created, and the result
will be returned to application.
3. Before the client issues the next request, the 'region' was moved to 'rsB'
and accepted another mutations for the two columns 'c1' and 'c2' as:
> put 'test_table', 'row', 'F:c1', 'value2', 'F:c2', 'value2'
4. Then, the client will receive a RegionMovedException when issuing next
request and will retry to open scanner on 'rsB'. The newly opened scanner will
higher mvcc than old data so that could read out column as : { column='F:c2'
with value='value2'} and return the result to application.
Therefore, the application will get data as:
'row'column='F:c1' value='value1'
'row'column='F:c2', value='value2'
The returned data is combined from two different mutations and violates the
row-level transaction.
{code}
The reason is that the newly opened scanner after region moved will get a
different mvcc. I am not sure whether this result is by design for scan if
partial row result is allowed. However, such row result combined from different
transactions may make the application have unexpected state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168616#comment-15168616 ] Liu Shaohui commented on HBASE-15338: - [~jingcheng...@intel.com] [~anoop.hbase] Agreed with you. Making cache on read in CacheConfig configurable will works. Thanks for your suggestions~ I will update the patch later~ > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff, HBASE-15338-trunk-v2.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[
https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168590#comment-15168590
]
Jingcheng Du commented on HBASE-15338:
--
bq. If we make cache on read in CacheConfig configurable and set it to false,
the index and meta blocks will not be cached.
If caching meta block is decided by cacheConf.shouldCacheDataOnRead(), and if
caching data index block is decided by the passed parameter from scanner.
Please correct me if I am wrong.
{code}
public boolean shouldCacheDataOnRead() {
+if (disableCacheDataBlock) {
+ return false;
+}
return isBlockCacheEnabled() && cacheDataOnRead;
}
{code}
In the patch, if the disableCacheDataBlock is true, no metadata can be cached?
And cacheConf.shouldCacheBlockOnRead in the current implementation is used for
caching data blocks, if the cacheblock is enabled the index blocks can be cachd
as well even the cache on read is disabled.
> Add a option to disable the data block cache for testing the performance of
> underlying file system
> --
>
> Key: HBASE-15338
> URL: https://issues.apache.org/jira/browse/HBASE-15338
> Project: HBase
> Issue Type: Improvement
> Components: integration tests
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15338-trunk-v1.diff, HBASE-15338-trunk-v2.diff
>
>
> When testing and comparing the performance of different file systems(HDFS,
> Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the
> affect of the HBase BlockCache and get the actually random read latency when
> data block is read from underlying file system. (Usually, the index block and
> meta block should be cached in memory in the testing).
> So we add a option in CacheConfig to disable the data block cache.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-15338: Attachment: HBASE-15338-trunk-v2.diff Update the comments > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff, HBASE-15338-trunk-v2.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168564#comment-15168564 ] Liu Shaohui commented on HBASE-15338: - Thanks [~anoop.hbase] When table is created with data block caching as false in CF config, the index and meta blocks will not be cached too according to the code. This is not what we want. > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[
https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168556#comment-15168556
]
Liu Shaohui commented on HBASE-15338:
-
Thanks [~jingcheng...@intel.com]
{quote}
I meant just making cache on read in CacheConfig configurable (a false value
for cache on read) can work as well instead of add a new global switch.
{quote}
If we make cache on read in CacheConfig configurable and set it to false, the
index and meta blocks will not be cached. This is not what we expect. Of
course, we can update the meaning of this config by changing the code.
And the data block may also be cached if we set hbase.rs.cacheblocksonwrite to
be true.
> Add a option to disable the data block cache for testing the performance of
> underlying file system
> --
>
> Key: HBASE-15338
> URL: https://issues.apache.org/jira/browse/HBASE-15338
> Project: HBase
> Issue Type: Improvement
> Components: integration tests
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15338-trunk-v1.diff
>
>
> When testing and comparing the performance of different file systems(HDFS,
> Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the
> affect of the HBase BlockCache and get the actually random read latency when
> data block is read from underlying file system. (Usually, the index block and
> meta block should be cached in memory in the testing).
> So we add a option in CacheConfig to disable the data block cache.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168550#comment-15168550 ] Anoop Sam John commented on HBASE-15338: Ya Jingcheng says same.. We can change it at CF level which is enough for testing. > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[
https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168549#comment-15168549
]
Anoop Sam John commented on HBASE-15338:
Ya after checking code that you mentioned we do
cacheBlock && cacheConf.shouldCacheBlockOnRead(category)
So if Scan says cache block as false, we will not cache any thing.
But one way is there . We won't set any thing wrt cache block in Scan/Get.
When table is created make the CF with data block caching as false
(setBlockCacheEnabled).
{code}
public boolean shouldCacheBlockOnRead(BlockCategory category) {
return isBlockCacheEnabled()
&& (cacheDataOnRead ||
category == BlockCategory.INDEX ||
category == BlockCategory.BLOOM ||
(prefetchOnOpen &&
(category != BlockCategory.META &&
category != BlockCategory.UNKNOWN)));
}
{code}
cacheDataOnRead contains value of HCD setting.
Can you test this..
Around this caching we have several settings already. Adding one more make
thing more complex.. That is why I was checking whether we can avoid this
addition and still achieve what u want. Thanks for the correcting me..
> Add a option to disable the data block cache for testing the performance of
> underlying file system
> --
>
> Key: HBASE-15338
> URL: https://issues.apache.org/jira/browse/HBASE-15338
> Project: HBase
> Issue Type: Improvement
> Components: integration tests
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15338-trunk-v1.diff
>
>
> When testing and comparing the performance of different file systems(HDFS,
> Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the
> affect of the HBase BlockCache and get the actually random read latency when
> data block is read from underlying file system. (Usually, the index block and
> meta block should be cached in memory in the testing).
> So we add a option in CacheConfig to disable the data block cache.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15339) Add archive tiers for date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-15339: -- Summary: Add archive tiers for date based tiered compaction (was: Add archive tiers for date based tiered compactions) > Add archive tiers for date based tiered compaction > -- > > Key: HBASE-15339 > URL: https://issues.apache.org/jira/browse/HBASE-15339 > Project: HBase > Issue Type: Improvement > Components: Compaction >Reporter: Duo Zhang > > For our MiCloud service, the old data is rarely touched but we still need to > keep it, so we want to put the data on inexpensive device and reduce > redundancy using EC to cut down the cost. > With date based tiered compaction introduced in HBASE-15181, new data and old > data can be placed in different tier. But the tier boundary moves as time > lapse so it is still possible that we do compaction on old tier which breaks > our block moving and EC work. > So here we want to introduce an "archive tier" to better fit our scenario. > Add an configuration called "archive unit", for example, year. That means, if > we find that the tier boundary is already in the previous year, then we reset > the boundary to the start of year and end of year, and if we want to do > compaction in this tier, just compact all files into one file. The file will > never be changed unless we force a major compaction so it is safe to apply EC > and other cost reducing approach on the file. And we make more tiers before > this tier year by year. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15339) Add archive tiers for date based tiered compactions
Duo Zhang created HBASE-15339: - Summary: Add archive tiers for date based tiered compactions Key: HBASE-15339 URL: https://issues.apache.org/jira/browse/HBASE-15339 Project: HBase Issue Type: Improvement Components: Compaction Reporter: Duo Zhang For our MiCloud service, the old data is rarely touched but we still need to keep it, so we want to put the data on inexpensive device and reduce redundancy using EC to cut down the cost. With date based tiered compaction introduced in HBASE-15181, new data and old data can be placed in different tier. But the tier boundary moves as time lapse so it is still possible that we do compaction on old tier which breaks our block moving and EC work. So here we want to introduce an "archive tier" to better fit our scenario. Add an configuration called "archive unit", for example, year. That means, if we find that the tier boundary is already in the previous year, then we reset the boundary to the start of year and end of year, and if we want to do compaction in this tier, just compact all files into one file. The file will never be changed unless we force a major compaction so it is safe to apply EC and other cost reducing approach on the file. And we make more tiers before this tier year by year. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168537#comment-15168537 ] Jingcheng Du commented on HBASE-15338: -- Thanks [~liushaohui]. I meant just making cache on read in CacheConfig configurable (a false value for cache on read) can work as well instead of add a new global switch. Now in CacheConfig it is always true unless it is disabled in cf. > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[
https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168533#comment-15168533
]
Liu Shaohui commented on HBASE-15338:
-
[~anoop.hbase]
{quote}
ut my thinking was when we specify cache blocks as false in Get/Scan, we will
consider that for DATA blocks only. The index blocks will get cached any way.
Did not see the code now.. Can check
{quote}
After the check the code in HFileReaderImpl.java#1533, the index blocks will be
also not cached when we specify cache blocks as false in Get/Scan, because the
var cacheBlock is false.
What's more, we don't like to change the client code when using 3rd-party
benchmark tools like YCSB.
{code}
// Cache the block if necessary
if (cacheBlock && cacheConf.shouldCacheBlockOnRead(category)) {
cacheConf.getBlockCache().cacheBlock(cacheKey,
cacheConf.shouldCacheCompressed(category) ? hfileBlock : unpacked,
cacheConf.isInMemory(), this.cacheConf.isCacheDataInL1());
}
{code}
> Add a option to disable the data block cache for testing the performance of
> underlying file system
> --
>
> Key: HBASE-15338
> URL: https://issues.apache.org/jira/browse/HBASE-15338
> Project: HBase
> Issue Type: Improvement
> Components: integration tests
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15338-trunk-v1.diff
>
>
> When testing and comparing the performance of different file systems(HDFS,
> Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the
> affect of the HBase BlockCache and get the actually random read latency when
> data block is read from underlying file system. (Usually, the index block and
> meta block should be cached in memory in the testing).
> So we add a option in CacheConfig to disable the data block cache.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[
https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168522#comment-15168522
]
Liu Shaohui commented on HBASE-15338:
-
[~chenheng] [~jingcheng...@intel.com]
{quote}
what's the difference if we just set hfile.block.cache.size to be 0.
{quote}
In this case, index blocks and meta blocks will not be cached and need to be
read from the file system for every get/scan.
The latency will be very bad and don't reflect the usual state of the hbase
cluster where the amount of data is more larger than the sum of memory. I think
tests for this case have no meanings.
> Add a option to disable the data block cache for testing the performance of
> underlying file system
> --
>
> Key: HBASE-15338
> URL: https://issues.apache.org/jira/browse/HBASE-15338
> Project: HBase
> Issue Type: Improvement
> Components: integration tests
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15338-trunk-v1.diff
>
>
> When testing and comparing the performance of different file systems(HDFS,
> Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the
> affect of the HBase BlockCache and get the actually random read latency when
> data block is read from underlying file system. (Usually, the index block and
> meta block should be cached in memory in the testing).
> So we add a option in CacheConfig to disable the data block cache.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168521#comment-15168521 ] Anoop Sam John commented on HBASE-15338: No he can not make cache size as 0. Because then even the index blocks also can not get cached. The need is avoid caching of DATA blocks only. But my thinking was when we specify cache blocks as false in Get/Scan, we will consider that for DATA blocks only. The index blocks will get cached any way. Did not see the code now.. Can check > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15215) TestBlockEvictionFromClient is flaky in jdk1.7 build
[
https://issues.apache.org/jira/browse/HBASE-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168518#comment-15168518
]
ramkrishna.s.vasudevan commented on HBASE-15215:
Pushed to master. Will keep this open. But not very sure if this will solve the
actual flakiness. But this test was intended to run with offheap bucketcache
only.
> TestBlockEvictionFromClient is flaky in jdk1.7 build
>
>
> Key: HBASE-15215
> URL: https://issues.apache.org/jira/browse/HBASE-15215
> Project: HBase
> Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-15215_offheap.patch
>
>
> This is the 2nd time I am noticing this.
> {code}
> Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 76.187 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.client.TestBlockEvictionFromClient
> testReverseScanWithCompaction(org.apache.hadoop.hbase.client.TestBlockEvictionFromClient)
> Time elapsed: 5.812 sec <<< FAILURE!
> java.lang.AssertionError: expected:<3> but was:<2>
> 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.TestBlockEvictionFromClient.testScanWithCompactionInternals(TestBlockEvictionFromClient.java:922)
> at
> org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.testReverseScanWithCompaction(TestBlockEvictionFromClient.java:857)
> {code}
> Generally the jdk1.8 build does not have this failure. Need to investigate
> the failure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-15338: Status: Patch Available (was: Open) > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-15338: Fix Version/s: 2.0.0 > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles
[
https://issues.apache.org/jira/browse/HBASE-15236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168512#comment-15168512
]
Hadoop QA commented on HBASE-15236:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
56s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 39s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 105m 38s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 104m 37s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 262m 46s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-26 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790029/HBASE-15236-master-v2.patch
|
| JIRA Issue | HBASE-15236 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
|
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168513#comment-15168513 ] ramkrishna.s.vasudevan commented on HBASE-15338: bq.Or use 0 as the block cache size for that RS/HM? This I have not tested. But how does this behave? I think in case of bucket cache it won't allow the cluster to start I suppose. Forgot the behaviour. > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clara Xiong updated HBASE-15181: Attachment: HBASE-15181-master-v3.patch > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168511#comment-15168511 ] Heng Chen commented on HBASE-15338: --- what's the difference if we just set hfile.block.cache.size to be 0. > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168508#comment-15168508 ] Jingcheng Du commented on HBASE-15338: -- Agree with [~anoopsamjohn]. Most of the cache settings can be set by Configuration in CacheConfig. The cache on read can be disabled in Get/Scan. Is this enough? Otherwise, is it ok to just make the cache on read configurable? Or use 0 as the block cache size for that RS/HM? > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[
https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168505#comment-15168505
]
Hadoop QA commented on HBASE-15332:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 18s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 40s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
35m 15s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 25s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 23s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 189m 5s {color}
| {color:red} root in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 148m 51s
{color} | {color:red} root in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 399m 28s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests |
hadoop.hbase.master.balancer.TestStochasticLoadBalancer2 |
| | hadoop.hbase.regionserver.TestRegionServerMetrics |
| | hadoop.hbase.TestStochasticBalancerJmxMetrics |
| | hadoop.hbase.quotas.TestQuotaThrottle |
| JDK v1.8.0_72 Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestMobSecureExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestMobExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestExportSnapshot |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
| | hadoop.hbase.client.TestBlockEvictionFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-25 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790013/HBASE-15332-v1.patch |
| JIRA Issue | HBASE-15332 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux eab85bc98f3f 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 40c5591 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/710/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/710/artifact/patchprocess/patch-unit-root-jdk1.7.0_95.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/710/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
https://builds.apache.org/job/PreCommit-HBASE-Build/710/artifact/patchprocess/patch-unit-root-jdk1.7.0_95.txt
|
| JDK v1.7.0_95 Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/710/testReport/ |
| modules | C: . U: . |
| Max memory used | 184MB |
| Powered by | Apache
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[
https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168498#comment-15168498
]
Liu Shaohui commented on HBASE-15338:
-
[~anoop.hbase]
{quote}
During these tests, we can specify cache blocks as false in Scan/Get and
achieve what you want?
{quote}
Not actually. If we specify cache blocks as false, the index blocks and meta
blocks need to be read from the underlying file system for Scan/Get, which is
not consistent with actual state of the HBase cluster. Usually the index block
and meta block can be cached in BlockCache. What we want to test is the latency
in the bad case when data block is not in cache and need to be read from the
file system for get.
> Add a option to disable the data block cache for testing the performance of
> underlying file system
> --
>
> Key: HBASE-15338
> URL: https://issues.apache.org/jira/browse/HBASE-15338
> Project: HBase
> Issue Type: Improvement
> Components: integration tests
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Attachments: HBASE-15338-trunk-v1.diff
>
>
> When testing and comparing the performance of different file systems(HDFS,
> Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the
> affect of the HBase BlockCache and get the actually random read latency when
> data block is read from underlying file system. (Usually, the index block and
> meta block should be cached in memory in the testing).
> So we add a option in CacheConfig to disable the data block cache.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168491#comment-15168491 ] stack commented on HBASE-15338: --- Patch LGTM. +1. Needs release note. See above comment by [~anoop.hbase] [~liushaohui] > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15329) Cross-Site Scripting: Reflected in table.jsp
[
https://issues.apache.org/jira/browse/HBASE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168485#comment-15168485
]
stack commented on HBASE-15329:
---
That would be excellent [~asamir] I will make this a subtask. You noticed that
I marked this minor, so if you have something more important to work on... go
for that instead but cool if this got a fix. You the man.
> Cross-Site Scripting: Reflected in table.jsp
>
>
> Key: HBASE-15329
> URL: https://issues.apache.org/jira/browse/HBASE-15329
> Project: HBase
> Issue Type: Bug
> Components: security
>Reporter: stack
>Priority: Minor
>
> Minor issue where we write back table name in a few places. Should clean it
> up:
> {code}
> } else {
> out.write("\nTable: ");
> out.print( fqtn );
> out.write("\n");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-15338: Attachment: HBASE-15338-trunk-v1.diff Patch for master branch > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Attachments: HBASE-15338-trunk-v1.diff > > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14798) NPE reporting server load causes regionserver abort; causes TestAcidGuarantee to fail
[
https://issues.apache.org/jira/browse/HBASE-14798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168476#comment-15168476
]
Jerry He commented on HBASE-14798:
--
Pushed to branch-1.1.
> NPE reporting server load causes regionserver abort; causes TestAcidGuarantee
> to fail
> -
>
> Key: HBASE-14798
> URL: https://issues.apache.org/jira/browse/HBASE-14798
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4
>
> Attachments: 14798.patch, 14798.patch
>
>
> Below crashed out a RS. Caused TestAcidGuarantees to fail because then there
> were not RS to assign too...
> {code}
> 2015-11-11 11:36:23,092 ERROR
> [B.defaultRpcServer.handler=4,queue=0,port=58655]
> master.MasterRpcServices(388): Region server
> asf907.gq1.ygridcore.net,55184,1447241756717 reported a fatal error:
> ABORTING region server asf907.gq1.ygridcore.net,55184,1447241756717:
> Unhandled: null
> Cause:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getOldestHfileTs(HRegion.java:1643)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.createRegionLoad(HRegionServer.java:1503)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.buildServerLoad(HRegionServer.java:1210)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.tryRegionServerReport(HRegionServer.java:1153)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:969)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.runRegionServer(MiniHBaseCluster.java:156)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.access$000(MiniHBaseCluster.java:108)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer$1.run(MiniHBaseCluster.java:140)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1637)
> at
> org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:307)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.run(MiniHBaseCluster.java:138)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Here is the failure:
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-Trunk_matrix/457/jdk=latest1.8,label=Hadoop/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.TestAcidGuarantees-output.txt
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14798) NPE reporting server load causes regionserver abort; causes TestAcidGuarantee to fail
[
https://issues.apache.org/jira/browse/HBASE-14798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-14798:
-
Fix Version/s: 1.1.4
> NPE reporting server load causes regionserver abort; causes TestAcidGuarantee
> to fail
> -
>
> Key: HBASE-14798
> URL: https://issues.apache.org/jira/browse/HBASE-14798
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4
>
> Attachments: 14798.patch, 14798.patch
>
>
> Below crashed out a RS. Caused TestAcidGuarantees to fail because then there
> were not RS to assign too...
> {code}
> 2015-11-11 11:36:23,092 ERROR
> [B.defaultRpcServer.handler=4,queue=0,port=58655]
> master.MasterRpcServices(388): Region server
> asf907.gq1.ygridcore.net,55184,1447241756717 reported a fatal error:
> ABORTING region server asf907.gq1.ygridcore.net,55184,1447241756717:
> Unhandled: null
> Cause:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getOldestHfileTs(HRegion.java:1643)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.createRegionLoad(HRegionServer.java:1503)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.buildServerLoad(HRegionServer.java:1210)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.tryRegionServerReport(HRegionServer.java:1153)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:969)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.runRegionServer(MiniHBaseCluster.java:156)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.access$000(MiniHBaseCluster.java:108)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer$1.run(MiniHBaseCluster.java:140)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1637)
> at
> org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:307)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.run(MiniHBaseCluster.java:138)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Here is the failure:
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-Trunk_matrix/457/jdk=latest1.8,label=Hadoop/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.TestAcidGuarantees-output.txt
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15329) Cross-Site Scripting: Reflected in table.jsp
[
https://issues.apache.org/jira/browse/HBASE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168474#comment-15168474
]
Samir Ahmic commented on HBASE-15329:
-
[~stack] since i have ongoing
[HBASE-15269|https://issues.apache.org/jira/browse/HBASE-15269] i can take this
one along.
> Cross-Site Scripting: Reflected in table.jsp
>
>
> Key: HBASE-15329
> URL: https://issues.apache.org/jira/browse/HBASE-15329
> Project: HBase
> Issue Type: Bug
> Components: security
>Reporter: stack
>Priority: Minor
>
> Minor issue where we write back table name in a few places. Should clean it
> up:
> {code}
> } else {
> out.write("\nTable: ");
> out.print( fqtn );
> out.write("\n");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[
https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168473#comment-15168473
]
Hadoop QA commented on HBASE-15181:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 58s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 58s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 21s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-server
(total was 83, now 79). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 18s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 3m 15s
{color} | {color:red} hbase-server introduced 1 new FindBugs issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 0s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 142m 41s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 110m 30s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 309m 37s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | storeFile must be non-null but is marked as nullable At
DateTieredCompactionPolicy.java:is marked as nullable At
DateTieredCompactionPolicy.java:[line 239] |
| JDK v1.8.0_72 Failed junit tests |
hadoop.hbase.client.TestBlockEvictionFromClient |
| | hadoop.hbase.regionserver.TestRegionServerMetrics |
| | hadoop.hbase.quotas.TestQuotaThrottle |
| JDK v1.8.0_72 Timed out junit tests |
[jira] [Commented] (HBASE-14798) NPE reporting server load causes regionserver abort; causes TestAcidGuarantee to fail
[
https://issues.apache.org/jira/browse/HBASE-14798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168472#comment-15168472
]
Jerry He commented on HBASE-14798:
--
I saw this problem in a production cluster running HBase 1.1.1
{noformat}
2016-02-24 14:28:50,354 FATAL
[regionserver/hadoop8.biginsights.com/10.200.50.144:60020]
regionserver.HRegionServer: ABORTING region server
hadoop8.biginsights.com,60020,1456280295877: Unhandled: null
java.lang.NullPointerException
at
org.apache.hadoop.hbase.regionserver.HRegion.getOldestHfileTs(HRegion.java:1613)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.createRegionLoad(HRegionServer.java:1463)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.buildServerLoad(HRegionServer.java:1187)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.tryRegionServerReport(HRegionServer.java:1130)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:947)
at java.lang.Thread.run(Thread.java:745)
2016-02-24 14:28:50,354 FATAL
[regionserver/hadoop8.biginsights.com/10.200.50.144:60020]
regionserver.HRegionServer: RegionServer abort: loaded coprocessors are: []
{noformat}
This important fix needs go to branch-1.1 as well.
> NPE reporting server load causes regionserver abort; causes TestAcidGuarantee
> to fail
> -
>
> Key: HBASE-14798
> URL: https://issues.apache.org/jira/browse/HBASE-14798
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 14798.patch, 14798.patch
>
>
> Below crashed out a RS. Caused TestAcidGuarantees to fail because then there
> were not RS to assign too...
> {code}
> 2015-11-11 11:36:23,092 ERROR
> [B.defaultRpcServer.handler=4,queue=0,port=58655]
> master.MasterRpcServices(388): Region server
> asf907.gq1.ygridcore.net,55184,1447241756717 reported a fatal error:
> ABORTING region server asf907.gq1.ygridcore.net,55184,1447241756717:
> Unhandled: null
> Cause:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getOldestHfileTs(HRegion.java:1643)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.createRegionLoad(HRegionServer.java:1503)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.buildServerLoad(HRegionServer.java:1210)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.tryRegionServerReport(HRegionServer.java:1153)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:969)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.runRegionServer(MiniHBaseCluster.java:156)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.access$000(MiniHBaseCluster.java:108)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer$1.run(MiniHBaseCluster.java:140)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1637)
> at
> org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:307)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.run(MiniHBaseCluster.java:138)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Here is the failure:
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-Trunk_matrix/457/jdk=latest1.8,label=Hadoop/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.TestAcidGuarantees-output.txt
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15293) Handle TableNotFound and IllegalArgument exceptions in table.jsp.
[ https://issues.apache.org/jira/browse/HBASE-15293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samir Ahmic updated HBASE-15293: Attachment: HBASE-15293_v1.patch Here is v1 with minor change avoiding write of unvalidated "fqtn" parameter. > Handle TableNotFound and IllegalArgument exceptions in table.jsp. > - > > Key: HBASE-15293 > URL: https://issues.apache.org/jira/browse/HBASE-15293 > Project: HBase > Issue Type: Sub-task > Components: UI >Affects Versions: 2.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Fix For: 2.0.0 > > Attachments: HBASE-15293_v0.patch, HBASE-15293_v1.patch > > > table.jsp accepts "name" parameter for table name and in case when table does > not exist or empty parameter is passed it will throw 500 error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168463#comment-15168463 ] Anoop Sam John commented on HBASE-15338: During these tests, we can specify cache blocks as false in Scan/Get and achieve what you want? > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14878) maven archetype: client application with shaded jars
[ https://issues.apache.org/jira/browse/HBASE-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168454#comment-15168454 ] Daniel Vimont commented on HBASE-14878: --- If appropriate at this point, could someone review this as needed and then push it through to the master branch? Then I can submit the mapreduce-oriented archetype, and potentially the hbase-spark-oriented archetype. I see that the 1.3 discussions are moving ahead, so once I get all these into the master branch, I'd be ready to backport all these to 1.3. > maven archetype: client application with shaded jars > > > Key: HBASE-14878 > URL: https://issues.apache.org/jira/browse/HBASE-14878 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: beginner > Attachments: HBASE-14878-v1.patch, HBASE-14878-v1.patch > > > Add new archetype for generation of hbase-shaded-client dependent project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
Liu Shaohui created HBASE-15338: --- Summary: Add a option to disable the data block cache for testing the performance of underlying file system Key: HBASE-15338 URL: https://issues.apache.org/jira/browse/HBASE-15338 Project: HBase Issue Type: Improvement Components: integration tests Reporter: Liu Shaohui Assignee: Liu Shaohui When testing and comparing the performance of different file systems(HDFS, Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the affect of the HBase BlockCache and get the actually random read latency when data block is read from underlying file system. (Usually, the index block and meta block should be cached in memory in the testing). So we add a option in CacheConfig to disable the data block cache. Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15338) Add a option to disable the data block cache for testing the performance of underlying file system
[ https://issues.apache.org/jira/browse/HBASE-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-15338: Priority: Minor (was: Major) > Add a option to disable the data block cache for testing the performance of > underlying file system > -- > > Key: HBASE-15338 > URL: https://issues.apache.org/jira/browse/HBASE-15338 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > > When testing and comparing the performance of different file systems(HDFS, > Azure blob storage, AWS S3 and so on) for HBase, it's better to avoid the > affect of the HBase BlockCache and get the actually random read latency when > data block is read from underlying file system. (Usually, the index block and > meta block should be cached in memory in the testing). > So we add a option in CacheConfig to disable the data block cache. > Suggestions are welcomed~ Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[
https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168436#comment-15168436
]
Hadoop QA commented on HBASE-15290:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 21s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 20s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 48s
{color} | {color:red} hbase-rest in master has 2 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 22s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 19s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 41s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 20s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 26s
{color} | {color:green} hbase-rest in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 3s
{color} | {color:green} hbase-rest in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 58m 18s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-26 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790055/HBASE-15290-checkAndPut_StyteFixes.patch
|
| JIRA Issue | HBASE-15290 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux b88796732956 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
|
[jira] [Updated] (HBASE-15205) Do not find the replication scope for every WAL#append()
[ https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15205: --- Status: Patch Available (was: Open) Also there is one checkstyle comment which talks about number of lines being > 150. I am not addressing that in this patch as it will be a bigger change. > Do not find the replication scope for every WAL#append() > > > Key: HBASE-15205 > URL: https://issues.apache.org/jira/browse/HBASE-15205 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15204_6.patch, HBASE-15205.patch, > HBASE-15205_1.patch, HBASE-15205_10.patch, HBASE-15205_11.patch, > HBASE-15205_2.patch, HBASE-15205_3.patch, HBASE-15205_4.patch, > HBASE-15205_6.patch, HBASE-15205_6.patch, HBASE-15205_7.patch, > HBASE-15205_8.patch, HBASE-15205_9.patch, ScopeWALEdits.jpg, > ScopeWALEdits_afterpatch.jpg > > > After the byte[] and char[] the other top contributor for lot of GC (though > it is only 2.86%) is the UTF_8.newDecoder. > This happens because for every WAL append we try to calculate the replication > scope associate with the families associated with the TableDescriptor. I > think per WAL append doing this is very costly and creates lot of garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15205) Do not find the replication scope for every WAL#append()
[ https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15205: --- Status: Open (was: Patch Available) > Do not find the replication scope for every WAL#append() > > > Key: HBASE-15205 > URL: https://issues.apache.org/jira/browse/HBASE-15205 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15204_6.patch, HBASE-15205.patch, > HBASE-15205_1.patch, HBASE-15205_10.patch, HBASE-15205_11.patch, > HBASE-15205_2.patch, HBASE-15205_3.patch, HBASE-15205_4.patch, > HBASE-15205_6.patch, HBASE-15205_6.patch, HBASE-15205_7.patch, > HBASE-15205_8.patch, HBASE-15205_9.patch, ScopeWALEdits.jpg, > ScopeWALEdits_afterpatch.jpg > > > After the byte[] and char[] the other top contributor for lot of GC (though > it is only 2.86%) is the UTF_8.newDecoder. > This happens because for every WAL append we try to calculate the replication > scope associate with the families associated with the TableDescriptor. I > think per WAL append doing this is very costly and creates lot of garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15205) Do not find the replication scope for every WAL#append()
[ https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15205: --- Attachment: HBASE-15205_11.patch Updated checkstyle and whitespaces in test case. Will wait for one more QA run if the test could run once again (Metrics related test cases are not stable). > Do not find the replication scope for every WAL#append() > > > Key: HBASE-15205 > URL: https://issues.apache.org/jira/browse/HBASE-15205 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15204_6.patch, HBASE-15205.patch, > HBASE-15205_1.patch, HBASE-15205_10.patch, HBASE-15205_11.patch, > HBASE-15205_2.patch, HBASE-15205_3.patch, HBASE-15205_4.patch, > HBASE-15205_6.patch, HBASE-15205_6.patch, HBASE-15205_7.patch, > HBASE-15205_8.patch, HBASE-15205_9.patch, ScopeWALEdits.jpg, > ScopeWALEdits_afterpatch.jpg > > > After the byte[] and char[] the other top contributor for lot of GC (though > it is only 2.86%) is the UTF_8.newDecoder. > This happens because for every WAL append we try to calculate the replication > scope associate with the families associated with the TableDescriptor. I > think per WAL append doing this is very costly and creates lot of garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15312) Update the dependences of pom for mini cluster in HBase Book
[ https://issues.apache.org/jira/browse/HBASE-15312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168425#comment-15168425 ] Liu Shaohui commented on HBASE-15312: - @Appy [~saint@gmail.com] [~eclark] Could you help to review the patch v2? Thanks~ > Update the dependences of pom for mini cluster in HBase Book > > > Key: HBASE-15312 > URL: https://issues.apache.org/jira/browse/HBASE-15312 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15312-trunk-v1.diff, HBASE-15312-trunk-v2.diff > > > In HBase book, the dependences of pom for mini cluster is outdated after > version 0.96. > See: > http://hbase.apache.org/book.html#_integration_testing_with_an_hbase_mini_cluster -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168415#comment-15168415 ] Hudson commented on HBASE-15128: FAILURE: Integrated in HBase-Trunk_matrix #739 (See [https://builds.apache.org/job/HBase-Trunk_matrix/739/]) HBASE-15128 Disable region splits and merges switch in master (chenheng: rev 24d481c5803e69a6190339cd8bb218b2c4585459) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java * hbase-shell/src/main/ruby/hbase/admin.rb * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/SnapshotProtos.java * hbase-shell/src/main/ruby/shell.rb * hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionImplementation.java * hbase-protocol/src/main/protobuf/Master.proto * hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java * hbase-shell/src/main/ruby/shell/commands/splitormerge_switch.rb * hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java * hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java * hbase-protocol/src/main/protobuf/ZooKeeper.proto * hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/SplitOrMergeTrackerManager.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSplitOrMergeStatus.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/MasterProtos.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * hbase-shell/src/main/ruby/shell/commands/splitormerge_enabled.rb Revert "HBASE-15128 Disable region splits and merges switch in master" (chenheng: rev bf4fcc30c62395e8db9fe52fde07c752f9e00e54) * hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * hbase-shell/src/main/ruby/shell.rb * hbase-shell/src/main/ruby/shell/commands/splitormerge_switch.rb * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/SnapshotProtos.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java * hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * hbase-shell/src/main/ruby/hbase/admin.rb * hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/SplitOrMergeTrackerManager.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSplitOrMergeStatus.java * hbase-shell/src/main/ruby/shell/commands/splitormerge_enabled.rb * hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionImplementation.java * hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java * hbase-protocol/src/main/protobuf/Master.proto * hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java * hbase-protocol/src/main/protobuf/ZooKeeper.proto * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/MasterProtos.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch, HBASE-15128_v8.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15311) Prevent NPE in BlockCacheViewTmpl
[ https://issues.apache.org/jira/browse/HBASE-15311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168416#comment-15168416 ] Hudson commented on HBASE-15311: FAILURE: Integrated in HBase-Trunk_matrix #739 (See [https://builds.apache.org/job/HBase-Trunk_matrix/739/]) HBASE-15311 Prevent NPE in BlockCacheViewTmpl. (stack: rev 75c57a04ddad2d7cf3435df1eba13541775319fb) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/BlockCacheViewTmpl.jamon > Prevent NPE in BlockCacheViewTmpl > - > > Key: HBASE-15311 > URL: https://issues.apache.org/jira/browse/HBASE-15311 > Project: HBase > Issue Type: Sub-task > Components: UI >Affects Versions: 2.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-15311_v0.patch > > > Currently we have this URL (rs-status?format=json=L1) for displaying > block cache stats in json format. If arbitrary parameter is supplied instead > of L1 it will cause NPE and we will display 500 error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15328) Unvalidated Redirect in HMaster
[
https://issues.apache.org/jira/browse/HBASE-15328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168380#comment-15168380
]
Heng Chen commented on HBASE-15328:
---
At least, we could check whether request.getServerName is our valid RS or not.
> Unvalidated Redirect in HMaster
> ---
>
> Key: HBASE-15328
> URL: https://issues.apache.org/jira/browse/HBASE-15328
> Project: HBase
> Issue Type: Bug
> Components: security
>Reporter: stack
>Priority: Minor
>
> See OWASP page on why we should clean it up someday:
> https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet
> Here is where we do the redirect:
> {code}
> @Override
> public void doGet(HttpServletRequest request,
> HttpServletResponse response) throws ServletException, IOException {
> String redirectUrl = request.getScheme() + "://"
> + request.getServerName() + ":" + regionServerInfoPort
> + request.getRequestURI();
> response.sendRedirect(redirectUrl);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15311) Prevent NPE in BlockCacheViewTmpl
[ https://issues.apache.org/jira/browse/HBASE-15311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168378#comment-15168378 ] Hudson commented on HBASE-15311: SUCCESS: Integrated in HBase-1.3-IT #519 (See [https://builds.apache.org/job/HBase-1.3-IT/519/]) HBASE-15311 Prevent NPE in BlockCacheViewTmpl. (stack: rev e28b01be5005d833d045456073c10a860760bf51) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/BlockCacheViewTmpl.jamon > Prevent NPE in BlockCacheViewTmpl > - > > Key: HBASE-15311 > URL: https://issues.apache.org/jira/browse/HBASE-15311 > Project: HBase > Issue Type: Sub-task > Components: UI >Affects Versions: 2.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-15311_v0.patch > > > Currently we have this URL (rs-status?format=json=L1) for displaying > block cache stats in json format. If arbitrary parameter is supplied instead > of L1 it will cause NPE and we will display 500 error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14703) not collect stats when call HTable.mutateRow
[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168370#comment-15168370 ] Heng Chen commented on HBASE-14703: --- Failed testcase due to HBASE-15222, has no relates with current patch. > not collect stats when call HTable.mutateRow > - > > Key: HBASE-14703 > URL: https://issues.apache.org/jira/browse/HBASE-14703 > Project: HBase > Issue Type: Bug >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0 > > Attachments: HBASE-14702_v5.2_addendum-addendum.patch, > HBASE-14703-5.2-addendum.patch, HBASE-14703-async.patch, > HBASE-14703-start.patch, HBASE-14703-v4.1.patch, HBASE-14703-v4.patch, > HBASE-14703-v6_with-check-and-mutate.patch, HBASE-14703.patch, > HBASE-14703_v1.patch, HBASE-14703_v10.patch, HBASE-14703_v10.patch, > HBASE-14703_v11.patch, HBASE-14703_v12.patch, HBASE-14703_v13.patch, > HBASE-14703_v2.patch, HBASE-14703_v3.patch, HBASE-14703_v5.1.patch, > HBASE-14703_v5.2.patch, HBASE-14703_v5.patch, HBASE-14703_v6-addendum.patch, > HBASE-14703_v6.patch, HBASE-14703_v7.patch, HBASE-14703_v8.patch, > HBASE-14703_v9.patch > > > We are trying to fix the stats implementation, by moving it out of the Result > object and into an Rpc payload (but not the 'cell payload', just as part of > the values returned from the request). This change will also us use easily > switch to AsyncProcess as the executor, and support stats, for nearly all the > rpc calls. However, that means when you upgrade the client or server, you > will lose stats visibility until the other side is upgraded. We could keep > around the Result based stats storage to accommodate the old api and send > both stats back from the server (in each result and in the rpc payload). > Note that we will still be wire compatible - protobufs mean we can just ride > over the lack of information. > The other tricky part of this is that Result has a > non-InterfaceAudience.Private getStatistics() method (along with two > InterfaceAudience.Private addResults and setStatistics methods), so we might > need a release to deprecate the getStats() method before throwing it out? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[
https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168356#comment-15168356
]
Hadoop QA commented on HBASE-15128:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
26s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 34s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 33s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 10m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 14s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 16s
{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 26s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 23s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 23s {color} |
{color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 23s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 26s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 26s {color} |
{color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 26s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m 0s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-client
(total was 473, now 473). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 8s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-server
(total was 337, now 337). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m 12s
{color} | {color:red} The applied patch generated 12 new rubocop issues (total
was 785, now 794). {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m 4s
{color} | {color:red} The applied patch generated 54 new ruby-lint issues
(total was 530, now 584). {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 5 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 47s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
11s {color} | {color:green} the patch passed
[jira] [Commented] (HBASE-14703) not collect stats when call HTable.mutateRow
[
https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168349#comment-15168349
]
Hadoop QA commented on HBASE-14703:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 5 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 25s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 15s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 18s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} hbaseprotoc {color} | {color:red} 0m 7s
{color} | {color:red} hbase-protocol in the patch failed. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 3s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 23s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
37s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 1s
{color} | {color:red} The patch has 17 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 38s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} hbaseprotoc {color} | {color:red} 0m 7s
{color} | {color:red} hbase-protocol in the patch failed. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
34s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 22s
{color} | {color:green} hbase-protocol in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 50s
{color} | {color:green} hbase-client in
[jira] [Commented] (HBASE-15311) Prevent NPE in BlockCacheViewTmpl
[ https://issues.apache.org/jira/browse/HBASE-15311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168333#comment-15168333 ] Hudson commented on HBASE-15311: FAILURE: Integrated in HBase-1.3 #574 (See [https://builds.apache.org/job/HBase-1.3/574/]) HBASE-15311 Prevent NPE in BlockCacheViewTmpl. (stack: rev e28b01be5005d833d045456073c10a860760bf51) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/BlockCacheViewTmpl.jamon > Prevent NPE in BlockCacheViewTmpl > - > > Key: HBASE-15311 > URL: https://issues.apache.org/jira/browse/HBASE-15311 > Project: HBase > Issue Type: Sub-task > Components: UI >Affects Versions: 2.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-15311_v0.patch > > > Currently we have this URL (rs-status?format=json=L1) for displaying > block cache stats in json format. If arbitrary parameter is supplied instead > of L1 it will cause NPE and we will display 500 error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15311) Prevent NPE in BlockCacheViewTmpl
[ https://issues.apache.org/jira/browse/HBASE-15311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168328#comment-15168328 ] Hudson commented on HBASE-15311: SUCCESS: Integrated in HBase-1.2 #563 (See [https://builds.apache.org/job/HBase-1.2/563/]) HBASE-15311 Prevent NPE in BlockCacheViewTmpl. (stack: rev 73e4cb43c00d962e81c940168fb3207a115ca5ce) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/BlockCacheViewTmpl.jamon > Prevent NPE in BlockCacheViewTmpl > - > > Key: HBASE-15311 > URL: https://issues.apache.org/jira/browse/HBASE-15311 > Project: HBase > Issue Type: Sub-task > Components: UI >Affects Versions: 2.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-15311_v0.patch > > > Currently we have this URL (rs-status?format=json=L1) for displaying > block cache stats in json format. If arbitrary parameter is supplied instead > of L1 it will cause NPE and we will display 500 error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajith updated HBASE-15290: -- Attachment: HBASE-15290-checkAndPut_StyteFixes.patch Fixed the Style issues reported in submitted files. I did not fix the findBugs report warnings as they are not related to the change and I don't have enough context to make the right call's there. > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: HBASE-15290-checkAndPut.patch, > HBASE-15290-checkAndPut_Comments.patch, > HBASE-15290-checkAndPut_Comments.patch, > HBASE-15290-checkAndPut_StyteFixes.patch, checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[
https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168320#comment-15168320
]
Hadoop QA commented on HBASE-15332:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 36s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 16s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 46s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 37s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 15s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 116m 56s
{color} | {color:red} root in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 116m 41s
{color} | {color:red} root in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 274m 52s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests | hadoop.hbase.mapred.TestTableMapReduceUtil
|
| | hadoop.hbase.regionserver.TestRegionServerMetrics |
| JDK v1.8.0_72 Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-25 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790009/HBASE-15332.patch |
| JIRA Issue | HBASE-15332 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux bd7e40bd3a6b 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 40c5591 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/706/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/706/artifact/patchprocess/patch-unit-root-jdk1.7.0_95.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/706/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
https://builds.apache.org/job/PreCommit-HBASE-Build/706/artifact/patchprocess/patch-unit-root-jdk1.7.0_95.txt
|
| JDK v1.7.0_95 Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/706/testReport/ |
| modules | C: . U: . |
| Max memory used | 467MB |
| Powered by | Apache Yetus 0.1.0 http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/706/console |
This message was automatically generated.
> Document how to take advantage of HDFS-6133 in HBase
>
>
> Key: HBASE-15332
> URL:
[jira] [Commented] (HBASE-15305) Fix a couple of incorrect anchors in HBase ref guide
[
https://issues.apache.org/jira/browse/HBASE-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168314#comment-15168314
]
Hadoop QA commented on HBASE-15305:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 35s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 14s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 0s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 30s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 16s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 91m 58s {color}
| {color:red} root in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 94m 15s {color}
| {color:red} root in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 240m 13s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-25 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790010/HBASE-15298-v1.patch |
| JIRA Issue | HBASE-15305 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux c9440ef8e50a 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 40c5591 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/708/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/708/artifact/patchprocess/patch-unit-root-jdk1.7.0_95.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/708/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
https://builds.apache.org/job/PreCommit-HBASE-Build/708/artifact/patchprocess/patch-unit-root-jdk1.7.0_95.txt
|
| JDK v1.7.0_95 Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/708/testReport/ |
| modules | C: . U: . |
| Max memory used | 186MB |
| Powered by | Apache Yetus 0.1.0 http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/708/console |
This message was automatically generated.
> Fix a couple of incorrect anchors in HBase ref guide
>
>
> Key: HBASE-15305
> URL: https://issues.apache.org/jira/browse/HBASE-15305
> Project: HBase
> Issue Type: Sub-task
> Components: documentation
>Reporter: Misty
[jira] [Updated] (HBASE-15295) MutateTableAccess.multiMutate() does not get high priority causing a deadlock
[
https://issues.apache.org/jira/browse/HBASE-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15295:
--
Attachment: hbase-15295_v3.patch
v3. Rebased and addressed findbugs, etc.
> MutateTableAccess.multiMutate() does not get high priority causing a deadlock
> -
>
> Key: HBASE-15295
> URL: https://issues.apache.org/jira/browse/HBASE-15295
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4
>
> Attachments: hbase-15295_v1.patch, hbase-15295_v1.patch,
> hbase-15295_v2.patch, hbase-15295_v3.patch
>
>
> We have seen this in a cluster with Phoenix secondary indexes leading to a
> deadlock. All handlers are busy waiting on the index updates to finish:
> {code}
> "B.defaultRpcServer.handler=50,queue=0,port=16020" #91 daemon prio=5
> os_prio=0 tid=0x7f29f64ba000 nid=0xab51 waiting on condition
> [0x7f29a8762000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000124f1d5c8> (a
> com.google.common.util.concurrent.AbstractFuture$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:275)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:111)
> at
> org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submit(BaseTaskRunner.java:66)
> at
> org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submitUninterruptible(BaseTaskRunner.java:99)
> at
> org.apache.phoenix.hbase.index.write.ParallelWriterIndexCommitter.write(ParallelWriterIndexCommitter.java:194)
> at
> org.apache.phoenix.hbase.index.write.IndexWriter.write(IndexWriter.java:179)
> at
> org.apache.phoenix.hbase.index.write.IndexWriter.writeAndKillYourselfOnFailure(IndexWriter.java:144)
> at
> org.apache.phoenix.hbase.index.write.IndexWriter.writeAndKillYourselfOnFailure(IndexWriter.java:134)
> at
> org.apache.phoenix.hbase.index.Indexer.doPostWithExceptions(Indexer.java:457)
> at org.apache.phoenix.hbase.index.Indexer.doPost(Indexer.java:406)
> at
> org.apache.phoenix.hbase.index.Indexer.postBatchMutate(Indexer.java:401)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$36.call(RegionCoprocessorHost.java:1006)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1673)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1748)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1705)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postBatchMutate(RegionCoprocessorHost.java:1002)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:3162)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2801)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2743)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:692)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:654)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2031)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32213)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2114)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:101)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> And the index region is trying to split, and is trying to do a meta update:
> {code}
> "regionserver//10.132.70.191:16020-splits-1454693389669" #1779
> prio=5 os_prio=0 tid=0x7f29e149c000 nid=0x5107 in Object.wait()
> [0x7f1f136d6000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168307#comment-15168307 ] Heng Chen commented on HBASE-15128: --- any other suggestions? If no, i will commit it today. > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch, HBASE-15128_v8.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168302#comment-15168302 ] Duo Zhang commented on HBASE-15181: --- +1. This feature is very important for our MiCloud service(https://i.mi.com/, a service like iCloud). And still need to add some new configurations to fit our requirements. Can open new issues when this getting in. Thanks. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15337) Document FIFO and date tiered compaction in the book
Enis Soztutar created HBASE-15337: - Summary: Document FIFO and date tiered compaction in the book Key: HBASE-15337 URL: https://issues.apache.org/jira/browse/HBASE-15337 Project: HBase Issue Type: Improvement Components: documentation Reporter: Enis Soztutar Fix For: 2.0.0, 1.3.0 We have two new compaction algorithms FIFO and Date tiered that are for time series data. We should document how to use them in the book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168238#comment-15168238 ] Ted Yu commented on HBASE-15128: Since v7 has been committed, you can apply the diff between v7 and v8 as addendum. > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch, HBASE-15128_v8.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heng Chen updated HBASE-15128: -- Attachment: HBASE-15128_v8.patch Address [~tedyu] comments, do i need to upload v8 to rb? Thanks ted! > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch, HBASE-15128_v8.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15144) Procedure v2 - Web UI displaying Store state
[ https://issues.apache.org/jira/browse/HBASE-15144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168199#comment-15168199 ] Hudson commented on HBASE-15144: FAILURE: Integrated in HBase-Trunk_matrix #738 (See [https://builds.apache.org/job/HBase-Trunk_matrix/738/]) HBASE-15144 Procedure v2 - Web UI displaying Store state (matteo.bertozzi: rev 40c55915e7a45a639adb7f7a370a04f38058ac26) * hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormatReader.java * hbase-server/src/main/resources/hbase-webapps/master/procedures.jsp * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/WALProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormat.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFile.java > Procedure v2 - Web UI displaying Store state > > > Key: HBASE-15144 > URL: https://issues.apache.org/jira/browse/HBASE-15144 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, UI >Reporter: Matteo Bertozzi >Assignee: Samir Ahmic >Priority: Minor > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15144-v4.patch, HBASE-15144_v0.patch, > HBASE-15144_v1.patch, HBASE-15144_v2.patch, HBASE-15144_v3.patch, > WALStoreUI.png, store-ui-sync-stats.png, store-ui-wals.png > > > The procedure webui page should show information about the WALProcedureStore. > * number/list/size of WALs active > * we may extract the "Sync wait %s, slotIndex=%s , totalSynced=%s (%s/sec)" > that today is only in LOG.trace() > * we have a getMillisToNextPeriodicRoll() and getMillisFromLastRoll() if > anyone want to see that -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168198#comment-15168198 ] Hudson commented on HBASE-15222: FAILURE: Integrated in HBase-Trunk_matrix #738 (See [https://builds.apache.org/job/HBase-Trunk_matrix/738/]) HBASE-15222 Addendum - Use less contended classes for metrics (eclark: rev 77133fd225df9f65be87ce97b38676d2bab48a71) * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/lib/MutableRangeHistogram.java * hbase-common/src/main/java/org/apache/hadoop/hbase/util/FastLongHistogram.java * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/lib/MutableHistogram.java > Use less contended classes for metrics > -- > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-ADD-0.patch, HBASE-15222-v1.patch, > HBASE-15222-v10.patch, HBASE-15222-v11.patch, HBASE-15222-v12.patch, > HBASE-15222-v13.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch, > HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch, > HBASE-15222-v9.patch, HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[
https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168184#comment-15168184
]
Ted Yu commented on HBASE-15128:
{code}
+ // Tracker for split and merge state
+ SplitOrMergeTrackerManager splitOrMergeTracker;
{code}
Looks like splitAndMergeTracker would be better name for the variable / class.
{code}
+ for (MasterSwitchType masterSwitchType : request.getSwitchTypesList()) {
+Admin.MasterSwitchType switchType = convert(masterSwitchType);
+boolean oldValue = master.isSplitOrMergeEnabled(switchType);
+boolean newValue = request.getEnabled();
{code}
The return value of request.getEnabled() wouldn't change in the for loop.
Please lift it outside the loop.
> Disable region splits and merges switch in master
> -
>
> Key: HBASE-15128
> URL: https://issues.apache.org/jira/browse/HBASE-15128
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Heng Chen
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15128.patch, HBASE-15128_v1.patch,
> HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch,
> HBASE-15128_v7.patch
>
>
> In large clusters where region splits are frequent, and HBCK runs take
> longer, the concurrent splits cause further problems in HBCK since HBCK
> assumes a static state for the region partition map. We have just seen a case
> where HBCK undo's a concurrently splitting region causing number of
> inconsistencies to go up.
> We can have a mode in master where splits and merges are disabled like the
> balancer and catalog janitor switches. Master will reject the split requests
> if regionservers decide to split. This switch can be turned on / off by the
> admins and also automatically by HBCK while it is running (similar to
> balancer switch being disabled by HBCK).
> HBCK should also disable the Catalog Janitor just in case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles
[
https://issues.apache.org/jira/browse/HBASE-15236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-15236:
-
Attachment: HBASE-15236-master-v2.patch
v2 patch. Should fix test failures (at least some of them).
> Inconsistent cell reads over multiple bulk-loaded HFiles
>
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-15236-master-v2.patch, HBASE-15236.patch,
> TestWithSingleHRegion.java, tables_data.zip
>
>
> If there are two bulkloaded hfiles in a region with same seqID, same
> timestamps and duplicate keys*, get and scan may return different values for
> a key. Not sure how this would happen, but one of our customer uploaded a
> dataset with 2 files in a single region and both having same bulk load
> timestamp. These files are small ~50M (I couldn't find any setting for max
> file size that could lead to 2 files). The range of keys in two hfiles are
> overlapping to some extent, but not fully (so the two files are because of
> region merge).
> In such a case, depending on file sizes (used in
> StoreFile.Comparators.SEQ_ID), we may get different values for the same cell
> (say "r", "cf:50") depending on what we call: get "r" "cf:50" or get "r"
> "cf:".
> To replicate this, i ran ImportTsv twice with 2 different csv files but same
> timestamp (-Dimporttsv.timestamp=1). Collected two resulting hfiles in a
> single directory and loaded with LoadIncrementalHFiles. Here are the commands.
> {noformat}
> //CSV files should be in hdfs:///user/hbase/tmp
> sudo -u hbase hbase org.apache.hadoop.hbase.mapreduce.ImportTsv
> -Dimporttsv.columns=HBASE_ROW_KEY,c:1,c:2,c:3,c:4,c:5,c:6
> -Dimporttsv.separator='|' -Dimporttsv.timestamp=1
> -Dimporttsv.bulk.output=hdfs:///user/hbase/1 t tmp
> {noformat}
> tables_data.zip contains three tables: t, t2, and t3.
> To load these tables and test with them, use the attached
> TestWithSingleHRegion.java. (Change ROOT_DIR and TABLE_NAME variables
> appropriately)
> Hfiles for table 't':
> 1) 07922ac90208445883b2ddc89c424c89 : length = 1094: KVs = (c:5, 55) (c:6, 66)
> 2) 143137fa4fa84625b4e8d1d84a494f08 : length = 1192: KVs = (c:1, 1) (c:2, 2)
> (c:3, 3) (c:4, 4) (c:5, 5) (c:6, 6)
> Get returns 5 where as Scan returns 55.
> On the other hand if I make the first hfile, the one with values 55 and 66
> bigger in size than second hfile, then:
> Get returns 55 where as Scan returns 55.
> This can be seen in table 't2'.
> Weird things:
> 1. Get consistently returns values from larger hfile.
> 2. Scan consistently returns 55.
> Reason:
> Explanation 1: We add StoreFileScanners to heap by iterating over list of
> store files which is kept sorted in DefaultStoreFileManger using
> StoreFile.Comparators.SEQ_ID. It sorts the file first by increasing seq id,
> then by decreasing filesize. So our larger files sizes are always in the
> start.
> Explanation 2: In KeyValueHeap.next(), if both current and this.heap.peek()
> scanners (type is StoreFileScanner in this case) point to KVs which compare
> as equal, we put back the current scanner into heap, and call pollRealKV() to
> get new one. While inserting, KVScannerComparator is used which compares the
> two (one already in heap and the one being inserted) as equal and inserts it
> after the existing one. \[1\]
> Say s1 is scanner over first hfile and s2 over second.
> 1. We scan with s2 to get values 1, 2, 3, 4
> 2. see that both scanners have c:5 as next key, put current scanner s2 back
> in heap, take s1 out
> 4. return 55, advance s1 to key c:6
> 5. compare c:6 to c:5, put back s2 in heap since it has larger key, take out
> s1
> 6. ignore it's value (there is code for that too), advance s2 to c:6
> Go back to step 2 with both scanners having c:6 as next key
> This is wrong because if we add a key between c:4 and c:5 to first hfile, say
> (c:44, foo) which makes s1 as the 'current' scanner when we hit step 2, then
> we'll get the values - 1, 2, 3, 4, foo, 5, 6.
> (try table t3)
> Fix:
> Assign priority ids to StoreFileScanners when inserting them into heap,
> latest hfiles get higher priority, and use them in KVComparator instead of
> just seq id.
> \[1\]
> [PriorityQueue.siftUp()|http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/PriorityQueue.java#586]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168178#comment-15168178 ] Heng Chen commented on HBASE-15128: --- Oh, sorry i just commit it to master, let me upload patch v7 to RB, if needed, i will revert commit on master. Thanks [~tedyu] > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168170#comment-15168170 ] Ted Yu commented on HBASE-15128: Heng: Patch on review board is v5. Can you upload the latest patch ? > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clara Xiong updated HBASE-15181: Attachment: HBASE-15181-master-v2.patch This new patch is to address HadoopQA complaints. I fixed checkstyle, changed annotation to suppress findbugs issue. The failed unit test doesn't seem to be related to the patch and passes locally. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14789) Enhance the current spark-hbase connector
[ https://issues.apache.org/jira/browse/HBASE-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168157#comment-15168157 ] Ted Malaska commented on HBASE-14789: - This looks really cool. Can we add a couple more. 5. Add support for DECIMAL 6. Add support for Nested Types 7. Add support for write with Bulk Load vs Puts with SparkSQL 8. Add support for pluggable change cell format (This is be implemented for item 2) > Enhance the current spark-hbase connector > - > > Key: HBASE-14789 > URL: https://issues.apache.org/jira/browse/HBASE-14789 > Project: HBase > Issue Type: Improvement >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: shc.pdf > > > This JIRA is to optimize the RDD construction in the current connector > implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15333) Enhance the filter to handle short, integer, long, float and double
[ https://issues.apache.org/jira/browse/HBASE-15333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168149#comment-15168149 ] Nick Dimiduk commented on HBASE-15333: -- Please consider using the OrderedBytes class for encoding values where serialized sort order matters (rowkeys, column qualifiers). > Enhance the filter to handle short, integer, long, float and double > --- > > Key: HBASE-15333 > URL: https://issues.apache.org/jira/browse/HBASE-15333 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang > > Currently, the range filter is based on the order of bytes. But for java > primitive type, such as short, int, long, double, float, etc, their order is > not consistent with their byte order, extra manipulation has to be in place > to take care of them correctly. > For example, for the integer range (-100, 100), the filter <= 1, the current > filter will return 0 and 1, and the right return value should be (-100, 1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15311) Prevent NPE in BlockCacheViewTmpl
[ https://issues.apache.org/jira/browse/HBASE-15311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168136#comment-15168136 ] Hudson commented on HBASE-15311: SUCCESS: Integrated in HBase-1.2-IT #448 (See [https://builds.apache.org/job/HBase-1.2-IT/448/]) HBASE-15311 Prevent NPE in BlockCacheViewTmpl. (stack: rev 73e4cb43c00d962e81c940168fb3207a115ca5ce) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/BlockCacheViewTmpl.jamon > Prevent NPE in BlockCacheViewTmpl > - > > Key: HBASE-15311 > URL: https://issues.apache.org/jira/browse/HBASE-15311 > Project: HBase > Issue Type: Sub-task > Components: UI >Affects Versions: 2.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-15311_v0.patch > > > Currently we have this URL (rs-status?format=json=L1) for displaying > block cache stats in json format. If arbitrary parameter is supplied instead > of L1 it will cause NPE and we will display 500 error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168126#comment-15168126 ] Heng Chen commented on HBASE-15128: --- Thanks [~enis], javadoc has been fixed. If no other suggestions, i will commit it later. > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[
https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168108#comment-15168108
]
Hadoop QA commented on HBASE-15187:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 42s
{color} | {color:red} hbase-rest in master has 2 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 3 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 24s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
39s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 44s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 20s
{color} | {color:green} hbase-rest in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 42s
{color} | {color:green} hbase-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 4s
{color} | {color:green} hbase-rest in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 50m 24s {color}
| {color:black} {color} |
\\
\\
||
[jira] [Commented] (HBASE-14789) Enhance the current spark-hbase connector
[ https://issues.apache.org/jira/browse/HBASE-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168106#comment-15168106 ] Zhan Zhang commented on HBASE-14789: Add a number extra jiras to improve the current connector. > Enhance the current spark-hbase connector > - > > Key: HBASE-14789 > URL: https://issues.apache.org/jira/browse/HBASE-14789 > Project: HBase > Issue Type: Improvement >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: shc.pdf > > > This JIRA is to optimize the RDD construction in the current connector > implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15144) Procedure v2 - Web UI displaying Store state
[ https://issues.apache.org/jira/browse/HBASE-15144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168103#comment-15168103 ] Hudson commented on HBASE-15144: SUCCESS: Integrated in HBase-1.3-IT #518 (See [https://builds.apache.org/job/HBase-1.3-IT/518/]) HBASE-15144 Procedure v2 - Web UI displaying Store state (matteo.bertozzi: rev 210ed97688a0aa18b5b337c14b5aa8eece77545f) * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/WALProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFile.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormatReader.java * hbase-server/src/main/resources/hbase-webapps/master/procedures.jsp * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormat.java > Procedure v2 - Web UI displaying Store state > > > Key: HBASE-15144 > URL: https://issues.apache.org/jira/browse/HBASE-15144 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, UI >Reporter: Matteo Bertozzi >Assignee: Samir Ahmic >Priority: Minor > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15144-v4.patch, HBASE-15144_v0.patch, > HBASE-15144_v1.patch, HBASE-15144_v2.patch, HBASE-15144_v3.patch, > WALStoreUI.png, store-ui-sync-stats.png, store-ui-wals.png > > > The procedure webui page should show information about the WALProcedureStore. > * number/list/size of WALs active > * we may extract the "Sync wait %s, slotIndex=%s , totalSynced=%s (%s/sec)" > that today is only in LOG.trace() > * we have a getMillisToNextPeriodicRoll() and getMillisFromLastRoll() if > anyone want to see that -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168102#comment-15168102 ] Hudson commented on HBASE-15222: SUCCESS: Integrated in HBase-1.3-IT #518 (See [https://builds.apache.org/job/HBase-1.3-IT/518/]) HBASE-15222 Addendum - Use less contended classes for metrics (eclark: rev 7c290e922a58f0e4d889b3e323152322152722a1) * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/lib/MutableHistogram.java * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/lib/MutableRangeHistogram.java * hbase-common/src/main/java/org/apache/hadoop/hbase/util/FastLongHistogram.java > Use less contended classes for metrics > -- > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-ADD-0.patch, HBASE-15222-v1.patch, > HBASE-15222-v10.patch, HBASE-15222-v11.patch, HBASE-15222-v12.patch, > HBASE-15222-v13.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch, > HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch, > HBASE-15222-v9.patch, HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168101#comment-15168101 ] Enis Soztutar commented on HBASE-15128: --- Oh, sorry I thought my +1 above still stands. Usually after a +1, if the patch author is a committer, I rely on them to fix the hadoopqa issues and do rebase or other mechanical changes and do the commit without a further need to review. Is javadoc warnings still applicable? Need to address those as well. You can do it at commit time (no need for another hadoopqa run if you think that the issue is solved). > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15311) Prevent NPE in BlockCacheViewTmpl
[ https://issues.apache.org/jira/browse/HBASE-15311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15311: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.1.4 1.2.1 1.3.0 2.0.0 Status: Resolved (was: Patch Available) Pushed to branch-1.1+ Thanks for the patch [~asamir] > Prevent NPE in BlockCacheViewTmpl > - > > Key: HBASE-15311 > URL: https://issues.apache.org/jira/browse/HBASE-15311 > Project: HBase > Issue Type: Sub-task > Components: UI >Affects Versions: 2.0.0 >Reporter: Samir Ahmic >Assignee: Samir Ahmic > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4 > > Attachments: HBASE-15311_v0.patch > > > Currently we have this URL (rs-status?format=json=L1) for displaying > block cache stats in json format. If arbitrary parameter is supplied instead > of L1 it will cause NPE and we will display 500 error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[
https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168099#comment-15168099
]
Hadoop QA commented on HBASE-15181:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
1s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
6s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 18 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 39s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 18s
{color} | {color:red} hbase-server introduced 1 new FindBugs issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 107m 3s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 101m 2s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 257m 23s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | storeFile must be non-null but is marked as nullable At
DateTieredCompactionPolicy.java:is marked as nullable At
DateTieredCompactionPolicy.java:[line 240] |
| JDK v1.8.0_72 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
| | hadoop.hbase.replication.TestReplicationKillSlaveRS |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.regionserver.TestRegionServerMetrics |
| |
[jira] [Commented] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[ https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168086#comment-15168086 ] Sean Busbey commented on HBASE-15332: - +1 presuming site building doesn't fall over in qabot. > Document how to take advantage of HDFS-6133 in HBase > > > Key: HBASE-15332 > URL: https://issues.apache.org/jira/browse/HBASE-15332 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 2.0.0 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-15332-v1.patch, HBASE-15332.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[
https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168084#comment-15168084
]
Sean Busbey commented on HBASE-15222:
-
{quote}
Sean Busbey Any changes to a module are not being picked up by dependent
modules in the pre-commit builds.
{quote}
Okay, sounds like the same situation as HBASE-15180. Paraphrasing [my longer
answer there about module
independence|https://issues.apache.org/jira/browse/HBASE-15180?focusedCommentId=15148845=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15148845]:
I think a new feature in Yetus that allowed projects to opt-in for "also build
any module that depends on a changed module" would be good general purpose
addition, but I am skeptical that it would be advisable for HBase as-is due to
the already extensive time it takes to get through our precommit checks.
A possible middle ground I did not mention there: we could make our personality
build the entire project at the top level if hbase-server is in the change
list, since it is the vast majority of our build/test time. That won't help all
the time, but it would have caught this specific issue.
> Use less contended classes for metrics
> --
>
> Key: HBASE-15222
> URL: https://issues.apache.org/jira/browse/HBASE-15222
> Project: HBase
> Issue Type: Bug
> Components: metrics
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15222-ADD-0.patch, HBASE-15222-v1.patch,
> HBASE-15222-v10.patch, HBASE-15222-v11.patch, HBASE-15222-v12.patch,
> HBASE-15222-v13.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch,
> HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch,
> HBASE-15222-v9.patch, HBASE-15222.patch
>
>
> Running the benchmarks now, but it looks like the results are pretty extreme.
> The locking in our histograms is pretty extreme.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15336) Support Dataframe writer to the connector
Zhan Zhang created HBASE-15336: -- Summary: Support Dataframe writer to the connector Key: HBASE-15336 URL: https://issues.apache.org/jira/browse/HBASE-15336 Project: HBase Issue Type: Sub-task Reporter: Zhan Zhang Currently, the connector only support read path. A complete solution should support both read and writer. This subtask add write support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15335) Add composite key support in row key
Zhan Zhang created HBASE-15335: -- Summary: Add composite key support in row key Key: HBASE-15335 URL: https://issues.apache.org/jira/browse/HBASE-15335 Project: HBase Issue Type: Sub-task Reporter: Zhan Zhang Add composite key filter support in the connector. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15334) Add avro support for spark hbase connector
Zhan Zhang created HBASE-15334: -- Summary: Add avro support for spark hbase connector Key: HBASE-15334 URL: https://issues.apache.org/jira/browse/HBASE-15334 Project: HBase Issue Type: Sub-task Reporter: Zhan Zhang Avro is a popular format for hbase storage. User may want the support natively in the connector. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15333) Enhance the filter to handle short, integer, long, float and double
Zhan Zhang created HBASE-15333: -- Summary: Enhance the filter to handle short, integer, long, float and double Key: HBASE-15333 URL: https://issues.apache.org/jira/browse/HBASE-15333 Project: HBase Issue Type: Sub-task Reporter: Zhan Zhang Currently, the range filter is based on the order of bytes. But for java primitive type, such as short, int, long, double, float, etc, their order is not consistent with their byte order, extra manipulation has to be in place to take care of them correctly. For example, for the integer range (-100, 100), the filter <= 1, the current filter will return 0 and 1, and the right return value should be (-100, 1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-15222) Use less contended classes for metrics
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168048#comment-15168048 ] Elliott Clark edited comment on HBASE-15222 at 2/25/16 10:54 PM: - [~busbey] Any changes to a module are not being picked up by dependent modules in the pre-commit builds. was (Author: eclark): [~busbey] Any changes to a module are not being picked up by dependent modules. > Use less contended classes for metrics > -- > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-ADD-0.patch, HBASE-15222-v1.patch, > HBASE-15222-v10.patch, HBASE-15222-v11.patch, HBASE-15222-v12.patch, > HBASE-15222-v13.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch, > HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch, > HBASE-15222-v9.patch, HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168048#comment-15168048 ] Elliott Clark commented on HBASE-15222: --- [~busbey] Any changes to a module are not being picked up by dependent modules. > Use less contended classes for metrics > -- > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-ADD-0.patch, HBASE-15222-v1.patch, > HBASE-15222-v10.patch, HBASE-15222-v11.patch, HBASE-15222-v12.patch, > HBASE-15222-v13.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch, > HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch, > HBASE-15222-v9.patch, HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15331) HBase Backup/Restore Phase 2: Optimized Restore operation
[ https://issues.apache.org/jira/browse/HBASE-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-15331: -- Description: The current implementation for restore uses WALReplay M/R job. This has performance and stability problems, since it uses HBase client API to insert data. We have to migrate to bulk load approach: generate hfiles directly from snapshot and incremental images. We run separate M/R job for every backup image between last FULL backup and current incremental backup we restore to and for every table in the list (image). If we have 10 tables and 30 days of incremental backup images - this results in 30x10 = 300 M/R jobs. MUST be optimized. (was: The current implementation for restore uses WALReplay M/R job. This has performance and stability problems, since it uses HBase client API to insert data. We have to migrate to bulk load approach: generate hfiles directly from snapshot and incremental images. We run separate M/R job for every backup image between last FULL backup and current incremental backup we restore to and for every table in the list (image). If we have 10 tables and 30 days of incremental backup images - this results in 30x10 = 300 M/R jobs.) > HBase Backup/Restore Phase 2: Optimized Restore operation > - > > Key: HBASE-15331 > URL: https://issues.apache.org/jira/browse/HBASE-15331 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > > The current implementation for restore uses WALReplay M/R job. This has > performance and stability problems, since it uses HBase client API to insert > data. We have to migrate to bulk load approach: generate hfiles directly from > snapshot and incremental images. We run separate M/R job for every backup > image between last FULL backup and current incremental backup we restore to > and for every table in the list (image). If we have 10 tables and 30 days of > incremental backup images - this results in 30x10 = 300 M/R jobs. MUST be > optimized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15331) HBase Backup/Restore Phase 2: Optimized Restore operation
[ https://issues.apache.org/jira/browse/HBASE-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-15331: -- Description: The current implementation for restore uses WALReplay M/R job. This has performance and stability problems, since it uses HBase client API to insert data. We have to migrate to bulk load approach: generate hfiles directly from snapshot and incremental images. We run separate M/R job for every backup image between last FULL backup and current incremental backup we restore to and for every table in the list (image). If we have 10 tables and 30 days of incremental backup images - this results in 30x10 = 300 M/R jobs. (was: The current implementation for restore uses WALReplay M/R job. This has performance and stability problems, since it uses HBase client API to insert data. We have to migrate to bulk load approach: generate hfiles directly from snapshot and incremental images.) > HBase Backup/Restore Phase 2: Optimized Restore operation > - > > Key: HBASE-15331 > URL: https://issues.apache.org/jira/browse/HBASE-15331 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > > The current implementation for restore uses WALReplay M/R job. This has > performance and stability problems, since it uses HBase client API to insert > data. We have to migrate to bulk load approach: generate hfiles directly from > snapshot and incremental images. We run separate M/R job for every backup > image between last FULL backup and current incremental backup we restore to > and for every table in the list (image). If we have 10 tables and 30 days of > incremental backup images - this results in 30x10 = 300 M/R jobs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[ https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-15332: Status: Open (was: Patch Available) > Document how to take advantage of HDFS-6133 in HBase > > > Key: HBASE-15332 > URL: https://issues.apache.org/jira/browse/HBASE-15332 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 2.0.0 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-15332-v1.patch, HBASE-15332.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[ https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-15332: Status: Patch Available (was: Open) > Document how to take advantage of HDFS-6133 in HBase > > > Key: HBASE-15332 > URL: https://issues.apache.org/jira/browse/HBASE-15332 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 2.0.0 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-15332-v1.patch, HBASE-15332.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[ https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-15332: Attachment: HBASE-15332-v1.patch Clarification about HDFS 2.7.0 / 2.7.1 in -v1 of the patch. > Document how to take advantage of HDFS-6133 in HBase > > > Key: HBASE-15332 > URL: https://issues.apache.org/jira/browse/HBASE-15332 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 2.0.0 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-15332-v1.patch, HBASE-15332.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[
https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167997#comment-15167997
]
Sean Busbey edited comment on HBASE-15332 at 2/25/16 10:28 PM:
---
{code}
+In the past, the generally accepted advice was to turn off the HDFS load
balancer and rely
+on the HBase balancer, since the HDFS balancer would degrade locality. This
advice
+is still valid if your HDFS version is lower than 2.7.0.
{code}
The first version HBase supports with this feature is 2.7.1, IIRC, because we
do not support running on 2.7.0.
was (Author: busbey):
{code}
+In the past, the generally accepted advice was to turn off the HDFS load
balancer and rely
+on the HBase balancer, since the HDFS balancer would degrade locality. This
advice
+is still valid if your HDFS version is lower than 2.7.0.
{code}
The first version HBase supports with this feature is 2.7.1 (IIRC).
> Document how to take advantage of HDFS-6133 in HBase
>
>
> Key: HBASE-15332
> URL: https://issues.apache.org/jira/browse/HBASE-15332
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.0.0
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15332.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15332) Document how to take advantage of HDFS-6133 in HBase
[
https://issues.apache.org/jira/browse/HBASE-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167997#comment-15167997
]
Sean Busbey commented on HBASE-15332:
-
{code}
+In the past, the generally accepted advice was to turn off the HDFS load
balancer and rely
+on the HBase balancer, since the HDFS balancer would degrade locality. This
advice
+is still valid if your HDFS version is lower than 2.7.0.
{code}
The first version HBase supports with this feature is 2.7.1 (IIRC).
> Document how to take advantage of HDFS-6133 in HBase
>
>
> Key: HBASE-15332
> URL: https://issues.apache.org/jira/browse/HBASE-15332
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.0.0
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15332.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167994#comment-15167994 ] Heng Chen commented on HBASE-15128: --- ping [~enis] > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, > HBASE-15128_v3.patch, HBASE-15128_v5.patch, HBASE-15128_v6.patch, > HBASE-15128_v7.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[ https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15187: --- Attachment: HBASE-15187.v13.patch Further shorten the length of RESTServer#main() > Integrate CSRF prevention filter to REST gateway > > > Key: HBASE-15187 > URL: https://issues.apache.org/jira/browse/HBASE-15187 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: HBASE-15187.v1.patch, HBASE-15187.v10.patch, > HBASE-15187.v11.patch, HBASE-15187.v12.patch, HBASE-15187.v13.patch, > HBASE-15187.v2.patch, HBASE-15187.v3.patch, HBASE-15187.v4.patch, > HBASE-15187.v5.patch, HBASE-15187.v6.patch, HBASE-15187.v7.patch, > HBASE-15187.v8.patch, HBASE-15187.v9.patch > > > HADOOP-12691 introduced a filter in Hadoop Common to help REST APIs guard > against cross-site request forgery attacks. > This issue tracks the integration of that filter into HBase REST gateway. > From REST section of refguide: > To delete a table, use a DELETE request with the /schema endpoint: > http://example.com:8000/schema > Suppose an attacker hosts a malicious web form on a domain under his control. > The form uses the DELETE action targeting a REST URL. Through social > engineering, the attacker tricks an authenticated user into accessing the > form and submitting it. > The browser sends the HTTP DELETE request to the REST gateway. > At REST gateway, the call is executed and user table is dropped -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14801) Enhance the Spark-HBase connector catalog with json format
[ https://issues.apache.org/jira/browse/HBASE-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167971#comment-15167971 ] Jonathan Hsieh commented on HBASE-14801: I plan on taking a look in the next few days. > Enhance the Spark-HBase connector catalog with json format > -- > > Key: HBASE-14801 > URL: https://issues.apache.org/jira/browse/HBASE-14801 > Project: HBase > Issue Type: Improvement >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: HBASE-14801-1.patch, HBASE-14801-2.patch, > HBASE-14801-3.patch, HBASE-14801-4.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15305) Fix a couple of incorrect anchors in HBase ref guide
[
https://issues.apache.org/jira/browse/HBASE-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-15305:
Status: Patch Available (was: Open)
> Fix a couple of incorrect anchors in HBase ref guide
>
>
> Key: HBASE-15305
> URL: https://issues.apache.org/jira/browse/HBASE-15305
> Project: HBase
> Issue Type: Sub-task
> Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15298-v1.patch, HBASE-15305.patch
>
>
> From HBASE-15298:
> {quote}
> After this patch is applied, there are still two missing asciidoc anchors,
> distributed.log.splitting and fail.fast.expired.active.master. These are
> related to features removed by HBASE-14053 and HBASE-10569. I think these
> anchors(and related texts) should be handled by someone who knows those
> issues well, so I retain them.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15305) Fix a couple of incorrect anchors in HBase ref guide
[
https://issues.apache.org/jira/browse/HBASE-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-15305:
Attachment: HBASE-15298-v1.patch
This version removes mention of the {{fail.fast.expired.active.master
property}}, which doesn't really exist anymore (since 0.98).
> Fix a couple of incorrect anchors in HBase ref guide
>
>
> Key: HBASE-15305
> URL: https://issues.apache.org/jira/browse/HBASE-15305
> Project: HBase
> Issue Type: Sub-task
> Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15298-v1.patch, HBASE-15305.patch
>
>
> From HBASE-15298:
> {quote}
> After this patch is applied, there are still two missing asciidoc anchors,
> distributed.log.splitting and fail.fast.expired.active.master. These are
> related to features removed by HBASE-14053 and HBASE-10569. I think these
> anchors(and related texts) should be handled by someone who knows those
> issues well, so I retain them.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15305) Fix a couple of incorrect anchors in HBase ref guide
[
https://issues.apache.org/jira/browse/HBASE-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-15305:
Status: Open (was: Patch Available)
> Fix a couple of incorrect anchors in HBase ref guide
>
>
> Key: HBASE-15305
> URL: https://issues.apache.org/jira/browse/HBASE-15305
> Project: HBase
> Issue Type: Sub-task
> Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15298-v1.patch, HBASE-15305.patch
>
>
> From HBASE-15298:
> {quote}
> After this patch is applied, there are still two missing asciidoc anchors,
> distributed.log.splitting and fail.fast.expired.active.master. These are
> related to features removed by HBASE-14053 and HBASE-10569. I think these
> anchors(and related texts) should be handled by someone who knows those
> issues well, so I retain them.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[
https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167950#comment-15167950
]
Hadoop QA commented on HBASE-15187:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 41s
{color} | {color:red} hbase-rest in master has 2 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 29s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-rest
(total was 30, now 30). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 3 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 0s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
23m 57s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 41s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 16s
{color} | {color:green} hbase-rest in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 40s
{color} | {color:green} hbase-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 2s
{color} | {color:green} hbase-rest in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}
