[jira] [Updated] (HBASE-16775) Flakey test with TestExportSnapshot#testExportRetry and TestMobExportSnapshot#testExportRetry
[
https://issues.apache.org/jira/browse/HBASE-16775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaxiang sun updated HBASE-16775:
-
Status: Patch Available (was: Open)
> Flakey test with TestExportSnapshot#testExportRetry and
> TestMobExportSnapshot#testExportRetry
> --
>
> Key: HBASE-16775
> URL: https://issues.apache.org/jira/browse/HBASE-16775
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: huaxiang sun
>Assignee: huaxiang sun
> Attachments: HBASE-16775.master.001.patch, disable.patch
>
>
> The root cause is that conf.setInt("mapreduce.map.maxattempts", 10) is not
> taken by the mapper job, so the retry is actually 0. Debugging to see why
> this is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16775) Flakey test with TestExportSnapshot#testExportRetry and TestMobExportSnapshot#testExportRetry
[
https://issues.apache.org/jira/browse/HBASE-16775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaxiang sun updated HBASE-16775:
-
Attachment: HBASE-16775.master.001.patch
> Flakey test with TestExportSnapshot#testExportRetry and
> TestMobExportSnapshot#testExportRetry
> --
>
> Key: HBASE-16775
> URL: https://issues.apache.org/jira/browse/HBASE-16775
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: huaxiang sun
>Assignee: huaxiang sun
> Attachments: HBASE-16775.master.001.patch, disable.patch
>
>
> The root cause is that conf.setInt("mapreduce.map.maxattempts", 10) is not
> taken by the mapper job, so the retry is actually 0. Debugging to see why
> this is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16859) Use Bytebuffer pool for non java clients specifically for scans/gets
[ https://issues.apache.org/jira/browse/HBASE-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584545#comment-15584545 ] Anoop Sam John commented on HBASE-16859: We dont need to add any extension to CIS or COS. COS already having ByteOuput based extension and this is from 3.1 release itself. ByteInput support for CIS is added (yet to be committed and there were some issue with the patch apply step in scripts. Stack will is on to it). Now we will need to implement ByteOutput for COS which works with ByteBuff. That impl class to be within hbase-server package only. (Where u have RpcServer) > Use Bytebuffer pool for non java clients specifically for scans/gets > > > Key: HBASE-16859 > URL: https://issues.apache.org/jira/browse/HBASE-16859 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > > In case of non java clients we still write the results and header into a on > demand byte[]. This can be changed to use the BBPool (onheap or offheap > buffer?). > But the basic problem is to identify if the response is for scans/gets. > - One easy way to do it is use the MethodDescriptor per Call and use the > name of the MethodDescriptor to identify it is a scan/get. But this will > pollute RpcServer by checking for scan/get type response. > - Other way is always set the result to cellScanner but we know that > isClientCellBlockSupported is going to false for non PB clients. So ignore > the cellscanner and go ahead with the results in PB. But this is not clean > - third one is that we already have a RpccallContext being passed to the RS. > In case of scan/gets/multiGets we already set a Rpccallback for shipped call. > So here on response we can check if the callback is not null and check for > isclientBlockSupported. In this case we can get the BB from the pool and > write the result and header to that BB. May be this looks clean? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16859) Use Bytebuffer pool for non java clients specifically for scans/gets
[ https://issues.apache.org/jira/browse/HBASE-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584536#comment-15584536 ] ramkrishna.s.vasudevan commented on HBASE-16859: One more thing to note here is that - if we want to do any new COS or CIS for ByteBuff - where will be the new impl be added? Inside shaded-protobuf package? If so can we access ByteBuff from common in that package? Just asking before looking into things. > Use Bytebuffer pool for non java clients specifically for scans/gets > > > Key: HBASE-16859 > URL: https://issues.apache.org/jira/browse/HBASE-16859 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > > In case of non java clients we still write the results and header into a on > demand byte[]. This can be changed to use the BBPool (onheap or offheap > buffer?). > But the basic problem is to identify if the response is for scans/gets. > - One easy way to do it is use the MethodDescriptor per Call and use the > name of the MethodDescriptor to identify it is a scan/get. But this will > pollute RpcServer by checking for scan/get type response. > - Other way is always set the result to cellScanner but we know that > isClientCellBlockSupported is going to false for non PB clients. So ignore > the cellscanner and go ahead with the results in PB. But this is not clean > - third one is that we already have a RpccallContext being passed to the RS. > In case of scan/gets/multiGets we already set a Rpccallback for shipped call. > So here on response we can check if the callback is not null and check for > isclientBlockSupported. In this case we can get the BB from the pool and > write the result and header to that BB. May be this looks clean? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16712) fix hadoop-3.0 profile mvn install
[ https://issues.apache.org/jira/browse/HBASE-16712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584532#comment-15584532 ] Hudson commented on HBASE-16712: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1806 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1806/]) HBASE-16712 fix mvn hadoop-3.0 profile for mvn install (jmhsieh: rev 8e100628a45028365486e47858dad786cebb49b9) * (edit) pom.xml * (edit) hbase-resource-bundle/src/main/resources/META-INF/NOTICE.vm * (edit) hbase-resource-bundle/src/main/resources/supplemental-models.xml * (edit) hbase-resource-bundle/src/main/resources/META-INF/LICENSE.vm HBASE-16712 ADDENDUM fix whitespace (jmhsieh: rev e1a6c94033bf4d986e72cd6109aac003b47e43d9) * (edit) hbase-resource-bundle/src/main/resources/supplemental-models.xml > fix hadoop-3.0 profile mvn install > -- > > Key: HBASE-16712 > URL: https://issues.apache.org/jira/browse/HBASE-16712 > Project: HBase > Issue Type: Bug > Components: build, hadoop3 >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: 2.0.0 > > Attachments: h2-deps, h3-deps, hbase-16712.v0.patch, > hbase-16712.v1.patch, hbase-16712.v2.patch, hbase-16712.v3.patch > > > After the compile is fixed, mvn install fails due to transitive dependencies > coming from hadoop3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16283) Batch Append/Increment will always fail if set ReturnResults to false
[
https://issues.apache.org/jira/browse/HBASE-16283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584530#comment-15584530
]
Hudson commented on HBASE-16283:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1806 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1806/])
HBASE-16283 Batch Append/Increment will always fail if set ReturnResults
(tedyu: rev 0c304a049bff130b971ef030746129cd6daaba7b)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestIncrementsFromClientSide.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestAtomicOperation.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestDurability.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> Batch Append/Increment will always fail if set ReturnResults to false
> -
>
> Key: HBASE-16283
> URL: https://issues.apache.org/jira/browse/HBASE-16283
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0.0, 1.1.5, 1.2.2
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: FailedCase.java, HBASE-16283.patch, HBASE-16283v2.patch,
> HBASE-16283v3.patch
>
>
> If set Append/Increment's ReturnResult attribute to false, and batch the
> appends/increments to server. The batch operation will always return false.
> The reason is that, since return result is set to false, append/increment
> will return null instead of Result object. But in
> ResponseConverter#getResults, there is some check code
> {code}
> if (requestRegionActionCount != responseRegionActionResultCount) {
> throw new IllegalStateException("Request mutation count=" +
> requestRegionActionCount +
> " does not match response mutation result count=" +
> responseRegionActionResultCount);
> }
> {code}
> That means if the result count is not meet with request mutation count, it
> will fail the request.
> The solution is simple, instead of returning a null result, returning a empty
> result if ReturnResult set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16145) MultiRowRangeFilter constructor shouldn't throw IOException
[ https://issues.apache.org/jira/browse/HBASE-16145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584533#comment-15584533 ] Hudson commented on HBASE-16145: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1806 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1806/]) HBASE-16145 MultiRowRangeFilter constructor shouldn't throw IOException (tedyu: rev 10840a51e851d3ea50749a9527310142a967dab3) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/RowCounter.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/filter/MultiRowRangeFilter.java > MultiRowRangeFilter constructor shouldn't throw IOException > --- > > Key: HBASE-16145 > URL: https://issues.apache.org/jira/browse/HBASE-16145 > Project: HBase > Issue Type: Wish >Reporter: Konstantin Ryakhovskiy >Assignee: Konstantin Ryakhovskiy >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16145.master.001.patch, > HBASE-16145.master.002.patch > > > MultiRowRangeFilter constructor declares IOException. > The constructor: > - sorts and merges incoming arguments - list of ranges, > - assigns sorted list to a private variable and does not do anything else. > There is no reason to declare IOException. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[ https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584529#comment-15584529 ] ramkrishna.s.vasudevan commented on HBASE-16783: My only concern was is it ok to add a new API in BBLOS though it is ugly? Since BBLOS handles curBuf it is difficult to bring out the buffer management outside without making other APIs also in that new class. Else for now can go with BBLOS itself but i fear we may have to do some refactoring later. thanks for the input. Will udpate the patch. > Use ByteBufferPool for the header and message during Rpc response > - > > Key: HBASE-16783 > URL: https://issues.apache.org/jira/browse/HBASE-16783 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Attachments: HBASE-16783.patch, HBASE-16783_1.patch, > HBASE-16783_2.patch, HBASE-16783_3.patch > > > With ByteBufferPool in place we could avoid the byte[] creation in > RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool > rather than creating byte[] every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[ https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584514#comment-15584514 ] Anoop Sam John commented on HBASE-16783: First of all this is not a manger for the pool. This is a manager for the bufs (that too from pool or on demand created) Now can u make use of the same BBLOS object for the remaining write as well? May be ugly. But can the BBLOS at least open up a method to return the cur buf which can be used to retrieve the buf for writing the header+ message? > Use ByteBufferPool for the header and message during Rpc response > - > > Key: HBASE-16783 > URL: https://issues.apache.org/jira/browse/HBASE-16783 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Attachments: HBASE-16783.patch, HBASE-16783_1.patch, > HBASE-16783_2.patch, HBASE-16783_3.patch > > > With ByteBufferPool in place we could avoid the byte[] creation in > RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool > rather than creating byte[] every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16698) Performance issue: handlers stuck waiting for CountDownLatch inside WALKey#getWriteEntry under high writing workload
[
https://issues.apache.org/jira/browse/HBASE-16698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584509#comment-15584509
]
stack commented on HBASE-16698:
---
[~allan163] Thanks for the questions
[~carp84] So, story is clearer now after the recent discussion. I'n +1 on the
patch for branch-1. Since I spent more time looking at the patch (smile), what
if you added a new constructor on HLogKey, one that took a WriteEntry. Then you
wouldn't need setPreAssignedWriteEntry nor preAssignedWriteEntry... just assign
writeEntry in the constructor. It'd make the patch smaller/clearer? But no
biggie.
What to do for 1.3? Backport but flip the switch to false? We'd have to ask
Mikhail. I should see if this patch applies to 1.2 because I know at least one
crew who'd be interested.
For Master, should we try and do something better? Try batching up sequenceid
assign. Apply a version of this patch in the meantime?
Thanks [~carp84]
> Performance issue: handlers stuck waiting for CountDownLatch inside
> WALKey#getWriteEntry under high writing workload
>
>
> Key: HBASE-16698
> URL: https://issues.apache.org/jira/browse/HBASE-16698
> Project: HBase
> Issue Type: Improvement
> Components: Performance
>Affects Versions: 1.2.3
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0
>
> Attachments: HBASE-16698.branch-1.patch,
> HBASE-16698.branch-1.v2.patch, HBASE-16698.patch, HBASE-16698.v2.patch,
> hadoop0495.et2.jstack
>
>
> As titled, on our production environment we observed 98 out of 128 handlers
> get stuck waiting for the CountDownLatch {{seqNumAssignedLatch}} inside
> {{WALKey#getWriteEntry}} under a high writing workload.
> After digging into the problem, we found that the problem is mainly caused by
> advancing mvcc in the append logic. Below is some detailed analysis:
> Under current branch-1 code logic, all batch puts will call
> {{WALKey#getWriteEntry}} after appending edit to WAL, and
> {{seqNumAssignedLatch}} is only released when the relative append call is
> handled by RingBufferEventHandler (see {{FSWALEntry#stampRegionSequenceId}}).
> Because currently we're using a single event handler for the ringbuffer, the
> append calls are handled one by one (actually lot's of our current logic
> depending on this sequential dealing logic), and this becomes a bottleneck
> under high writing workload.
> The worst part is that by default we only use one WAL per RS, so appends on
> all regions are dealt with in sequential, which causes contention among
> different regions...
> To fix this, we could also take use of the "sequential appends" mechanism,
> that we could grab the WriteEntry before publishing append onto ringbuffer
> and use it as sequence id, only that we need to add a lock to make "grab
> WriteEntry" and "append edit" a transaction. This will still cause contention
> inside a region but could avoid contention between different regions. This
> solution is already verified in our online environment and proved to be
> effective.
> Notice that for master (2.0) branch since we already change the write
> pipeline to sync before writing memstore (HBASE-15158), this issue only
> exists for the ASYNC_WAL writes scenario.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16345) RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer Exceptions
[ https://issues.apache.org/jira/browse/HBASE-16345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-16345: - Attachment: HBASE-16345.branch-1.001.patch Resumit branch-1 patch to trigger another qa run. > RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer > Exceptions > -- > > Key: HBASE-16345 > URL: https://issues.apache.org/jira/browse/HBASE-16345 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun > Attachments: HBASE-16345-v001.patch, HBASE-16345.branch-1.001.patch, > HBASE-16345.branch-1.001.patch, HBASE-16345.master.001.patch, > HBASE-16345.master.002.patch, HBASE-16345.master.003.patch, > HBASE-16345.master.004.patch, HBASE-16345.master.005.patch, > HBASE-16345.master.005.patch > > > Update for the description. Debugged more at this front based on the comments > from Enis. > The cause is that for the primary replica, if its retry is exhausted too > fast, f.get() [1] returns ExecutionException. This Exception needs to be > ignored and continue with the replicas. > The other issue is that after adding calls for the replicas, if the first > completed task gets ExecutionException (due to the retry exhausted), it > throws the exception to the client[2]. > In this case, it needs to loop through these tasks, waiting for the success > one. If no one succeeds, throw exception. > Similar for the scan as well > [1] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L197 > [2] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L219 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16836) Implement increment and append
[ https://issues.apache.org/jira/browse/HBASE-16836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-16836: -- Attachment: HBASE-16836-v2.patch Fix TestMultiParallel. > Implement increment and append > -- > > Key: HBASE-16836 > URL: https://issues.apache.org/jira/browse/HBASE-16836 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16836-v1.patch, HBASE-16836-v2.patch, > HBASE-16836.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584474#comment-15584474 ] Duo Zhang commented on HBASE-15536: --- I haven't tested it recently. You can post your result here or in a new jira and I can help figuring out the problem. Thanks. > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536-v3.patch, HBASE-15536-v4.patch, HBASE-15536-v5.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16854) refactor the org.apache.hadoop.hbase.client.Action
[
https://issues.apache.org/jira/browse/HBASE-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584464#comment-15584464
]
Hadoop QA commented on HBASE-16854:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s
{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: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: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
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 44s {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} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 56s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 81m 10s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 127m 55s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.master.procedure.TestServerCrashProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestModifyTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestAddColumnFamilyProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestRestoreSnapshotProcedure |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833867/HBASE-16854.v1.patch |
| JIRA Issue | HBASE-16854 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux e252790536eb 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 / 10840a5 |
| Default Java | 1.8.0_101 |
| findbugs | v3.0.0 |
| unit |
[jira] [Commented] (HBASE-16698) Performance issue: handlers stuck waiting for CountDownLatch inside WALKey#getWriteEntry under high writing workload
[
https://issues.apache.org/jira/browse/HBASE-16698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584453#comment-15584453
]
stack commented on HBASE-16698:
---
Let me answer [~enis] I just went through this issue again and the patch.
* Our write path has gone through a bunch of change. Some stepped (The Xiaomi
redo, the intro of ringbuffer). Others evolutions (Reorder because rely on mvcc
instead of row locks). Its can be hard to keep it all straight. For example,
[~allan163]'s comment above is against 1.1 but [~carp84] patch is for the next
version on -- 1.2 but patched back to 1.1.
* Agree we should pick an approach with fall-back just-in-case. The patch here
has that. Patch also has the benefit of having been run in production showing
good numbers.
* The lock is region-scoped. It is not across the ringbuffer. The RB can make
progress on other region appends.
* The perf gain looks to the result of two phenomenon: 1. parallelism: a
single thread stamping every edit with a sequence id -- having to cross a
region-scoped synchronize on each impression -- marching in order over all
appends looks to be slower than a stamping that is done with some parallelism
as each handler does its own imprint though there is friction as each handler
has to contend on the reentrant lock with other handlers that are in the same
region trying to do the same thing; and 2. no-wait: with the new patch, the
handler can make progress after calling append where before not until the RB
consumer on the other side of the RB had let go of the latch.
The RB is good as transmission between N handlers and the single WAL writer.
The notion that the single consumer manage sequenceid assignment in line w/ the
appends to WAL, while appealing because of its simplicity, seems to hold up
throughput because our sequenceid is by region.
> Performance issue: handlers stuck waiting for CountDownLatch inside
> WALKey#getWriteEntry under high writing workload
>
>
> Key: HBASE-16698
> URL: https://issues.apache.org/jira/browse/HBASE-16698
> Project: HBase
> Issue Type: Improvement
> Components: Performance
>Affects Versions: 1.2.3
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0
>
> Attachments: HBASE-16698.branch-1.patch,
> HBASE-16698.branch-1.v2.patch, HBASE-16698.patch, HBASE-16698.v2.patch,
> hadoop0495.et2.jstack
>
>
> As titled, on our production environment we observed 98 out of 128 handlers
> get stuck waiting for the CountDownLatch {{seqNumAssignedLatch}} inside
> {{WALKey#getWriteEntry}} under a high writing workload.
> After digging into the problem, we found that the problem is mainly caused by
> advancing mvcc in the append logic. Below is some detailed analysis:
> Under current branch-1 code logic, all batch puts will call
> {{WALKey#getWriteEntry}} after appending edit to WAL, and
> {{seqNumAssignedLatch}} is only released when the relative append call is
> handled by RingBufferEventHandler (see {{FSWALEntry#stampRegionSequenceId}}).
> Because currently we're using a single event handler for the ringbuffer, the
> append calls are handled one by one (actually lot's of our current logic
> depending on this sequential dealing logic), and this becomes a bottleneck
> under high writing workload.
> The worst part is that by default we only use one WAL per RS, so appends on
> all regions are dealt with in sequential, which causes contention among
> different regions...
> To fix this, we could also take use of the "sequential appends" mechanism,
> that we could grab the WriteEntry before publishing append onto ringbuffer
> and use it as sequence id, only that we need to add a lock to make "grab
> WriteEntry" and "append edit" a transaction. This will still cause contention
> inside a region but could avoid contention between different regions. This
> solution is already verified in our online environment and proved to be
> effective.
> Notice that for master (2.0) branch since we already change the write
> pipeline to sync before writing memstore (HBASE-15158), this issue only
> exists for the ASYNC_WAL writes scenario.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16836) Implement increment and append
[
https://issues.apache.org/jira/browse/HBASE-16836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584448#comment-15584448
]
Hadoop QA commented on HBASE-16836:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 20s
{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: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 20s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 41s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 8s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
1s {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 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 33s {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} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 54s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 73m 29s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 118m 41s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestMultiParallel |
| Timed out junit tests | org.apache.hadoop.hbase.client.TestReplicasClient |
| | org.apache.hadoop.hbase.client.TestAdmin2 |
| | org.apache.hadoop.hbase.client.TestHCM |
| |
org.apache.hadoop.hbase.client.TestRestoreSnapshotFromClientWithRegionReplicas |
| | org.apache.hadoop.hbase.client.TestMobCloneSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833866/HBASE-16836-v1.patch |
| JIRA Issue | HBASE-16836 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 25b2b3b7dac2 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 / 10840a5 |
| Default Java | 1.8.0_101 |
| findbugs |
[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL
[ https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584446#comment-15584446 ] ramkrishna.s.vasudevan commented on HBASE-15536: [~Apache9] Do you have any latest reports on this? what do you think when running with AsyncWAL on a single node. I think now we need to see how well we are performing with AsyncWAL and with offheap write path. In my recent runs with PE tool and 10 cols per row with 50 threads I found AsyncWAL to be performing slower than the default WAL. (for the default memstore).. Today I have another cluster where I can also do some profiling. But wanted to get your feedback. > Make AsyncFSWAL as our default WAL > -- > > Key: HBASE-15536 > URL: https://issues.apache.org/jira/browse/HBASE-15536 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, > HBASE-15536-v3.patch, HBASE-15536-v4.patch, HBASE-15536-v5.patch, > HBASE-15536.patch > > > As it should be predicated on passing basic cluster ITBLL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[ https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584426#comment-15584426 ] ramkrishna.s.vasudevan commented on HBASE-16783: bq. But this new class should not be responsible check size and do any sort of writes or so. I agree to this. This patch as I said the BBoolManager is not doing more that what it is supposed to do. But if there is one person managing the pool for the current read request it is better it knows what is the current buffer active. So if allow the BBLOS to accept a pool and have the curBuf getting updated in the BBLOS, now if I need to get the curBuf only for someother operation if there is enough remaining length in the curBuf how should it be done? Because the entire logic of curBuf updation is self contained in BBLOS now. > Use ByteBufferPool for the header and message during Rpc response > - > > Key: HBASE-16783 > URL: https://issues.apache.org/jira/browse/HBASE-16783 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Attachments: HBASE-16783.patch, HBASE-16783_1.patch, > HBASE-16783_2.patch, HBASE-16783_3.patch > > > With ByteBufferPool in place we could avoid the byte[] creation in > RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool > rather than creating byte[] every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16608) Introducing the ability to merge ImmutableSegments without copy-compaction or SQM usage
[ https://issues.apache.org/jira/browse/HBASE-16608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584416#comment-15584416 ] ramkrishna.s.vasudevan commented on HBASE-16608: [~anastas] I did not comment on RB because Anoop had already raised the concern about proceeding with this merge way. Its better we discuss in meeting and then proceed. How ever from my side i have completed some runs with this patch and I could see more full GCs now. The bug is not there that we saw previously but there are more GC activity now. HEnce wrt patch I thought I could wait for further discussion before reviewing it. Thank you. > Introducing the ability to merge ImmutableSegments without copy-compaction or > SQM usage > --- > > Key: HBASE-16608 > URL: https://issues.apache.org/jira/browse/HBASE-16608 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-16417-V02.patch, HBASE-16417-V04.patch, > HBASE-16417-V06.patch, HBASE-16417-V07.patch, HBASE-16417-V08.patch, > HBASE-16417-V10.patch, HBASE-16608-V01.patch, HBASE-16608-V03.patch, > HBASE-16608-V04.patch, HBASE-16608-V08.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16414) Improve performance for RPC encryption with Apache Common Crypto
[ https://issues.apache.org/jira/browse/HBASE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584410#comment-15584410 ] ramkrishna.s.vasudevan commented on HBASE-16414: [~apurtell], [~apurtell] All comments from [~Apache9] also has been addressed wrt to Netty clients. Do you have some comments now? There are two +1s. But its better you can check this once as this is related to security before this is commited. Thank you. > Improve performance for RPC encryption with Apache Common Crypto > > > Key: HBASE-16414 > URL: https://issues.apache.org/jira/browse/HBASE-16414 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 2.0.0 >Reporter: Colin Ma >Assignee: Colin Ma > Attachments: HBASE-16414.001.patch, HBASE-16414.002.patch, > HBASE-16414.003.patch, HBASE-16414.004.patch, HBASE-16414.005.patch, > HBASE-16414.006.patch, HBASE-16414.007.patch, HBASE-16414.008.patch, > HBASE-16414.009.patch, HbaseRpcEncryptionWithCrypoto.docx > > > Hbase RPC encryption is enabled by setting “hbase.rpc.protection” to > "privacy". With the token authentication, it utilized DIGEST-MD5 mechanisms > for secure authentication and data protection. For DIGEST-MD5, it uses DES, > 3DES or RC4 to do encryption and it is very slow, especially for Scan. This > will become the bottleneck of the RPC throughput. > Apache Commons Crypto is a cryptographic library optimized with AES-NI. It > provides Java API for both cipher level and Java stream level. Developers can > use it to implement high performance AES encryption/decryption with the > minimum code and effort. Compare with the current implementation of > org.apache.hadoop.hbase.io.crypto.aes.AES, Crypto supports both JCE Cipher > and OpenSSL Cipher which is better performance than JCE Cipher. User can > configure the cipher type and the default is JCE Cipher. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16345) RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer Exceptions
[ https://issues.apache.org/jira/browse/HBASE-16345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584396#comment-15584396 ] Esteban Gutierrez commented on HBASE-16345: --- Thanks [~huaxiang] can you want to resubmit your patch to see if the OOME persists? > RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer > Exceptions > -- > > Key: HBASE-16345 > URL: https://issues.apache.org/jira/browse/HBASE-16345 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun > Attachments: HBASE-16345-v001.patch, HBASE-16345.branch-1.001.patch, > HBASE-16345.master.001.patch, HBASE-16345.master.002.patch, > HBASE-16345.master.003.patch, HBASE-16345.master.004.patch, > HBASE-16345.master.005.patch, HBASE-16345.master.005.patch > > > Update for the description. Debugged more at this front based on the comments > from Enis. > The cause is that for the primary replica, if its retry is exhausted too > fast, f.get() [1] returns ExecutionException. This Exception needs to be > ignored and continue with the replicas. > The other issue is that after adding calls for the replicas, if the first > completed task gets ExecutionException (due to the retry exhausted), it > throws the exception to the client[2]. > In this case, it needs to loop through these tasks, waiting for the success > one. If no one succeeds, throw exception. > Similar for the scan as well > [1] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L197 > [2] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L219 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16867) Check ACLs for remote HBaseLock
[ https://issues.apache.org/jira/browse/HBASE-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-16867: - Attachment: HBASE-16867.master.002.patch > Check ACLs for remote HBaseLock > --- > > Key: HBASE-16867 > URL: https://issues.apache.org/jira/browse/HBASE-16867 > Project: HBase > Issue Type: Sub-task >Reporter: Appy >Assignee: Appy > Attachments: HBASE-16867.master.001.patch, > HBASE-16867.master.002.patch > > > HBaseLock was added in HBASE-16744 to allow clients to take locks on > namespace/table/regions. Check acls for the 2 rpcs that were added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16867) Check ACLs for remote HBaseLock
[ https://issues.apache.org/jira/browse/HBASE-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-16867: - Attachment: HBASE-16867.master.001.patch > Check ACLs for remote HBaseLock > --- > > Key: HBASE-16867 > URL: https://issues.apache.org/jira/browse/HBASE-16867 > Project: HBase > Issue Type: Sub-task >Reporter: Appy >Assignee: Appy > Attachments: HBASE-16867.master.001.patch, > HBASE-16867.master.002.patch > > > HBaseLock was added in HBASE-16744 to allow clients to take locks on > namespace/table/regions. Check acls for the 2 rpcs that were added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-16868) Avoid appending table to a peer which replicates all tables
[
https://issues.apache.org/jira/browse/HBASE-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reassigned HBASE-16868:
--
Assignee: Guanghao Zhang
> Avoid appending table to a peer which replicates all tables
> ---
>
> Key: HBASE-16868
> URL: https://issues.apache.org/jira/browse/HBASE-16868
> Project: HBase
> Issue Type: New Feature
> Components: Replication
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>
> First add a new peer by shell cmd.
> {code}
> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
> {code}
> If we don't set namespaces and table cfs in peer config. It means replicate
> all tables to the peer cluster.
> Then append a table to the peer config.
> {code}
> append_peer_tableCFs '1', {"table1" => []}
> {code}
> Then this peer will only replicate table1 to the peer cluster. It changes to
> replicate only one table from replicate all tables in the cluster. It is very
> easy to misuse in production cluster. So we should avoid appending table to a
> peer which replicates all table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-16868) Avoid appending table to a peer which replicates all tables
Guanghao Zhang created HBASE-16868:
--
Summary: Avoid appending table to a peer which replicates all
tables
Key: HBASE-16868
URL: https://issues.apache.org/jira/browse/HBASE-16868
Project: HBase
Issue Type: New Feature
Components: Replication
Affects Versions: 2.0.0
Reporter: Guanghao Zhang
First add a new peer by shell cmd.
{code}
add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
{code}
If we don't set namespaces and table cfs in peer config. It means replicate all
tables to the peer cluster.
Then append a table to the peer config.
{code}
append_peer_tableCFs '1', {"table1" => []}
{code}
Then this peer will only replicate table1 to the peer cluster. It changes to
replicate only one table from replicate all tables in the cluster. It is very
easy to misuse in production cluster. So we should avoid appending table to a
peer which replicates all table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16867) Check ACLs for remote HBaseLock
[ https://issues.apache.org/jira/browse/HBASE-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-16867: - Issue Type: Sub-task (was: Bug) Parent: HBASE-14350 > Check ACLs for remote HBaseLock > --- > > Key: HBASE-16867 > URL: https://issues.apache.org/jira/browse/HBASE-16867 > Project: HBase > Issue Type: Sub-task >Reporter: Appy >Assignee: Appy > > HBaseLock was added in HBASE-16744 to allow clients to take locks on > namespace/table/regions. Check acls for the 2 rpcs that were added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16867) Check ACLs for remote HBaseLock
Appy created HBASE-16867: Summary: Check ACLs for remote HBaseLock Key: HBASE-16867 URL: https://issues.apache.org/jira/browse/HBASE-16867 Project: HBase Issue Type: Bug Reporter: Appy Assignee: Appy HBaseLock was added in HBASE-16744 to allow clients to take locks on namespace/table/regions. Check acls for the 2 rpcs that were added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16866) Avoid NPE in AsyncRequestFutureImpl#updateStats
[
https://issues.apache.org/jira/browse/HBASE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-16866:
--
Attachment: HBASE-16866.v1.patch
address [~tedyu]'s comment
> Avoid NPE in AsyncRequestFutureImpl#updateStats
> ---
>
> Key: HBASE-16866
> URL: https://issues.apache.org/jira/browse/HBASE-16866
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16866.v0.patch, HBASE-16866.v1.patch
>
>
> If region disables the stats, it won’t response any
> ClientProtos.RegionLoadStats to client. So the NPE will happen in
> AsyncRequestFutureImpl#updateStats.
> We should use relevant log instead of NPE because the data manipulation
> shouldn’t be broken by statistics.
> {noformat}
> protected void updateStats(ServerName server, Map MultiResponse.RegionResult> results) {
> …
> ClientProtos.RegionLoadStats stat = regionStats.getValue().getStat();
> RegionLoadStats regionLoadstats =
> ProtobufUtil.createRegionLoadStats(stat);
> …
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16856) Exception message in SyncRunner.run() should print currentSequence
[
https://issues.apache.org/jira/browse/HBASE-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584236#comment-15584236
]
Hudson commented on HBASE-16856:
FAILURE: Integrated in Jenkins build HBase-1.4 #475 (See
[https://builds.apache.org/job/HBase-1.4/475/])
HBASE-16856 Exception message in SyncRunner.run() should print (tedyu: rev
08498c684835ac37700bd6fca22f9c2d47d70797)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
> Exception message in SyncRunner.run() should print currentSequence
> --
>
> Key: HBASE-16856
> URL: https://issues.apache.org/jira/browse/HBASE-16856
> Project: HBase
> Issue Type: Bug
> Components: wal
>Affects Versions: 2.0.0, 1.2.2, 1.1.7
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16856.patch
>
>
> A very small bug, a typo in exception message:
> {code}
> if (syncFutureSequence > currentSequence) {
> throw new IllegalStateException("currentSequence=" +
> syncFutureSequence
> + ", syncFutureSequence=" + syncFutureSequence);
> }
> {code}
> It should print currentSequence and syncFutureSequence, but print two
> syncFutureSequence
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16866) Avoid NPE in AsyncRequestFutureImpl#updateStats
[
https://issues.apache.org/jira/browse/HBASE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-16866:
--
Status: Open (was: Patch Available)
> Avoid NPE in AsyncRequestFutureImpl#updateStats
> ---
>
> Key: HBASE-16866
> URL: https://issues.apache.org/jira/browse/HBASE-16866
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16866.v0.patch
>
>
> If region disables the stats, it won’t response any
> ClientProtos.RegionLoadStats to client. So the NPE will happen in
> AsyncRequestFutureImpl#updateStats.
> We should use relevant log instead of NPE because the data manipulation
> shouldn’t be broken by statistics.
> {noformat}
> protected void updateStats(ServerName server, Map MultiResponse.RegionResult> results) {
> …
> ClientProtos.RegionLoadStats stat = regionStats.getValue().getStat();
> RegionLoadStats regionLoadstats =
> ProtobufUtil.createRegionLoadStats(stat);
> …
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16866) Avoid NPE in AsyncRequestFutureImpl#updateStats
[
https://issues.apache.org/jira/browse/HBASE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-16866:
--
Status: Patch Available (was: Open)
> Avoid NPE in AsyncRequestFutureImpl#updateStats
> ---
>
> Key: HBASE-16866
> URL: https://issues.apache.org/jira/browse/HBASE-16866
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16866.v0.patch, HBASE-16866.v1.patch
>
>
> If region disables the stats, it won’t response any
> ClientProtos.RegionLoadStats to client. So the NPE will happen in
> AsyncRequestFutureImpl#updateStats.
> We should use relevant log instead of NPE because the data manipulation
> shouldn’t be broken by statistics.
> {noformat}
> protected void updateStats(ServerName server, Map MultiResponse.RegionResult> results) {
> …
> ClientProtos.RegionLoadStats stat = regionStats.getValue().getStat();
> RegionLoadStats regionLoadstats =
> ProtobufUtil.createRegionLoadStats(stat);
> …
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16855) Avoid NPE in MetricsConnection’s construction
[
https://issues.apache.org/jira/browse/HBASE-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584237#comment-15584237
]
Hudson commented on HBASE-16855:
FAILURE: Integrated in Jenkins build HBase-1.4 #475 (See
[https://builds.apache.org/job/HBase-1.4/475/])
HBASE-16855 Avoid NPE in MetricsConnection’s construction (ChiaPing (tedyu: rev
6df7554d299ce72e6d8dca35c5de119a47f5594d)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/MetricsConnection.java
* (edit)
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestMetricsConnection.java
> Avoid NPE in MetricsConnection’s construction
> -
>
> Key: HBASE-16855
> URL: https://issues.apache.org/jira/browse/HBASE-16855
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16855.branch-1.v0.patch, HBASE-16855.v0.patch,
> HBASE-16855.v1.patch
>
>
> a) The batch pool may not be assigned a value in the ConnectionImpl’s
> construction.
> b) The meta pool always be null in the ConnectionImpl’s construction.
> For reasons outlined above, the NPE may happen in MetricsConnection’s
> construction
> {noformat}
> final ThreadPoolExecutor batchPool = (ThreadPoolExecutor)
> conn.getCurrentBatchPool();
> final ThreadPoolExecutor metaPool = (ThreadPoolExecutor)
> conn.getCurrentMetaLookupPool();
> this.registry.register(name(this.getClass(), "executorPoolActiveThreads",
> scope),
> new RatioGauge() {
> @Override
> protected Ratio getRatio() {
> return Ratio.of(batchPool.getActiveCount(),
> batchPool.getMaximumPoolSize());
> }
> });
> this.registry.register(name(this.getClass(), "metaPoolActiveThreads",
> scope),
> new RatioGauge() {
> @Override
> protected Ratio getRatio() {
> return Ratio.of(metaPool.getActiveCount(),
> metaPool.getMaximumPoolSize());
> }
> });
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16414) Improve performance for RPC encryption with Apache Common Crypto
[ https://issues.apache.org/jira/browse/HBASE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Ma updated HBASE-16414: - Attachment: HBASE-16414.009.patch Update patch according to the comments from review board. > Improve performance for RPC encryption with Apache Common Crypto > > > Key: HBASE-16414 > URL: https://issues.apache.org/jira/browse/HBASE-16414 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 2.0.0 >Reporter: Colin Ma >Assignee: Colin Ma > Attachments: HBASE-16414.001.patch, HBASE-16414.002.patch, > HBASE-16414.003.patch, HBASE-16414.004.patch, HBASE-16414.005.patch, > HBASE-16414.006.patch, HBASE-16414.007.patch, HBASE-16414.008.patch, > HBASE-16414.009.patch, HbaseRpcEncryptionWithCrypoto.docx > > > Hbase RPC encryption is enabled by setting “hbase.rpc.protection” to > "privacy". With the token authentication, it utilized DIGEST-MD5 mechanisms > for secure authentication and data protection. For DIGEST-MD5, it uses DES, > 3DES or RC4 to do encryption and it is very slow, especially for Scan. This > will become the bottleneck of the RPC throughput. > Apache Commons Crypto is a cryptographic library optimized with AES-NI. It > provides Java API for both cipher level and Java stream level. Developers can > use it to implement high performance AES encryption/decryption with the > minimum code and effort. Compare with the current implementation of > org.apache.hadoop.hbase.io.crypto.aes.AES, Crypto supports both JCE Cipher > and OpenSSL Cipher which is better performance than JCE Cipher. User can > configure the cipher type and the default is JCE Cipher. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16866) Avoid NPE in AsyncRequestFutureImpl#updateStats
[
https://issues.apache.org/jira/browse/HBASE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ChiaPing Tsai updated HBASE-16866:
--
Description:
If region disables the stats, it won’t response any
ClientProtos.RegionLoadStats to client. So the NPE will happen in
AsyncRequestFutureImpl#updateStats.
We should use relevant log instead of NPE because the data manipulation
shouldn’t be broken by statistics.
{noformat}
protected void updateStats(ServerName server, Map results) {
…
ClientProtos.RegionLoadStats stat = regionStats.getValue().getStat();
RegionLoadStats regionLoadstats =
ProtobufUtil.createRegionLoadStats(stat);
…
}
{noformat}
was:
If region disables the stats, it won’t response any
ClientProtos.RegionLoadStats to client. So the NEP will happen in
AsyncRequestFutureImpl#updateStats.
We should use relevant log instead of NEP because the data manipulation
shouldn’t be broken by statistics.
{noformat}
protected void updateStats(ServerName server, Map results) {
…
ClientProtos.RegionLoadStats stat = regionStats.getValue().getStat();
RegionLoadStats regionLoadstats =
ProtobufUtil.createRegionLoadStats(stat);
…
}
{noformat}
> Avoid NPE in AsyncRequestFutureImpl#updateStats
> ---
>
> Key: HBASE-16866
> URL: https://issues.apache.org/jira/browse/HBASE-16866
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16866.v0.patch
>
>
> If region disables the stats, it won’t response any
> ClientProtos.RegionLoadStats to client. So the NPE will happen in
> AsyncRequestFutureImpl#updateStats.
> We should use relevant log instead of NPE because the data manipulation
> shouldn’t be broken by statistics.
> {noformat}
> protected void updateStats(ServerName server, Map MultiResponse.RegionResult> results) {
> …
> ClientProtos.RegionLoadStats stat = regionStats.getValue().getStat();
> RegionLoadStats regionLoadstats =
> ProtobufUtil.createRegionLoadStats(stat);
> …
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16854) refactor the org.apache.hadoop.hbase.client.Action
[ https://issues.apache.org/jira/browse/HBASE-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChiaPing Tsai updated HBASE-16854: -- Status: Patch Available (was: Open) > refactor the org.apache.hadoop.hbase.client.Action > -- > > Key: HBASE-16854 > URL: https://issues.apache.org/jira/browse/HBASE-16854 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16854.v0.patch, HBASE-16854.v1.patch > > > a) According to the previous comments, the Action doesn’t apply the generic. > b) Action implements the Comparable, but the Action#compareTo cast the > object to Action. > For reasons outlined above, we should refactor the Action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16854) refactor the org.apache.hadoop.hbase.client.Action
[ https://issues.apache.org/jira/browse/HBASE-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChiaPing Tsai updated HBASE-16854: -- Attachment: HBASE-16854.v1.patch address [~tedyu]'s comment. Move the test code of Action into TestAsncProcess > refactor the org.apache.hadoop.hbase.client.Action > -- > > Key: HBASE-16854 > URL: https://issues.apache.org/jira/browse/HBASE-16854 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16854.v0.patch, HBASE-16854.v1.patch > > > a) According to the previous comments, the Action doesn’t apply the generic. > b) Action implements the Comparable, but the Action#compareTo cast the > object to Action. > For reasons outlined above, we should refactor the Action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16836) Implement increment and append
[ https://issues.apache.org/jira/browse/HBASE-16836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-16836: -- Attachment: HBASE-16836-v1.patch Address the comments on rb. > Implement increment and append > -- > > Key: HBASE-16836 > URL: https://issues.apache.org/jira/browse/HBASE-16836 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-16836-v1.patch, HBASE-16836.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16854) refactor the org.apache.hadoop.hbase.client.Action
[ https://issues.apache.org/jira/browse/HBASE-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ChiaPing Tsai updated HBASE-16854: -- Status: Open (was: Patch Available) > refactor the org.apache.hadoop.hbase.client.Action > -- > > Key: HBASE-16854 > URL: https://issues.apache.org/jira/browse/HBASE-16854 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16854.v0.patch > > > a) According to the previous comments, the Action doesn’t apply the generic. > b) Action implements the Comparable, but the Action#compareTo cast the > object to Action. > For reasons outlined above, we should refactor the Action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16345) RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer Exceptions
[ https://issues.apache.org/jira/browse/HBASE-16345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584202#comment-15584202 ] huaxiang sun commented on HBASE-16345: -- Unittest failure is due to running out of memory. Running org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFilesSplitRecovery Exception in thread "process reaper" Exception in thread "Thread-2483" Exception in thread "Thread-2495" Exception in thread "Thread-2487" java.lang.OutOfMemoryError: Java heap space Exception in thread "Thread-2499" java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:2694) at java.lang.String.(String.java:203) at java.lang.StringBuffer.toString(StringBuffer.java:561) at java.io.BufferedReader.readLine(BufferedReader.java:352) at java.io.BufferedReader.readLine(BufferedReader.java:382) at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66) java.lang.OutOfMemoryError: Java heap space at java.lang.UNIXProcess$ProcessPipeInputStream.drainInputStream(UNIXProcess.java:320) at java.lang.UNIXProcess$ProcessPipeInputStream.processExited(UNIXProcess.java:333) at java.lang.UNIXProcess.processExited(UNIXProcess.java:241) at java.lang.UNIXProcess$4.run(UNIXProcess.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2367) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:535) at java.lang.StringBuffer.append(StringBuffer.java:322) at java.io.BufferedReader.readLine(BufferedReader.java:363) at java.io.BufferedReader.readLine(BufferedReader.java:382) at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66) Running org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat Exception in thread "Thread-2505" Exception in thread "Thread-2507" java.lang.OutOfMemoryError: Java heap space > RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer > Exceptions > -- > > Key: HBASE-16345 > URL: https://issues.apache.org/jira/browse/HBASE-16345 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun > Attachments: HBASE-16345-v001.patch, HBASE-16345.branch-1.001.patch, > HBASE-16345.master.001.patch, HBASE-16345.master.002.patch, > HBASE-16345.master.003.patch, HBASE-16345.master.004.patch, > HBASE-16345.master.005.patch, HBASE-16345.master.005.patch > > > Update for the description. Debugged more at this front based on the comments > from Enis. > The cause is that for the primary replica, if its retry is exhausted too > fast, f.get() [1] returns ExecutionException. This Exception needs to be > ignored and continue with the replicas. > The other issue is that after adding calls for the replicas, if the first > completed task gets ExecutionException (due to the retry exhausted), it > throws the exception to the client[2]. > In this case, it needs to loop through these tasks, waiting for the success > one. If no one succeeds, throw exception. > Similar for the scan as well > [1] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L197 > [2] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L219 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16345) RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer Exceptions
[ https://issues.apache.org/jira/browse/HBASE-16345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584195#comment-15584195 ] huaxiang sun commented on HBASE-16345: -- The findbug warning is as the following, I am not sure if it is related with the patch. Bug type RV_RETURN_VALUE_IGNORED (click for details) In class org.apache.hadoop.hbase.regionserver.HRegionServer In method org.apache.hadoop.hbase.regionserver.HRegionServer.initializeZooKeeper() Called method java.util.concurrent.CountDownLatch.await(long, TimeUnit) At HRegionServer.java:[line 807] > RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer > Exceptions > -- > > Key: HBASE-16345 > URL: https://issues.apache.org/jira/browse/HBASE-16345 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun > Attachments: HBASE-16345-v001.patch, HBASE-16345.branch-1.001.patch, > HBASE-16345.master.001.patch, HBASE-16345.master.002.patch, > HBASE-16345.master.003.patch, HBASE-16345.master.004.patch, > HBASE-16345.master.005.patch, HBASE-16345.master.005.patch > > > Update for the description. Debugged more at this front based on the comments > from Enis. > The cause is that for the primary replica, if its retry is exhausted too > fast, f.get() [1] returns ExecutionException. This Exception needs to be > ignored and continue with the replicas. > The other issue is that after adding calls for the replicas, if the first > completed task gets ExecutionException (due to the retry exhausted), it > throws the exception to the client[2]. > In this case, it needs to loop through these tasks, waiting for the success > one. If no one succeeds, throw exception. > Similar for the scan as well > [1] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L197 > [2] > https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerWithReadReplicas.java#L219 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16345) RpcRetryingCallerWithReadReplicas#call() should catch some RegionServer Exceptions
[
https://issues.apache.org/jira/browse/HBASE-16345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584161#comment-15584161
]
Hadoop QA commented on HBASE-16345:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 11m 13s
{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: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 16s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
55s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s
{color} | {color:green} branch-1 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 52s
{color} | {color:red} hbase-server in branch-1 has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} branch-1 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
4s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
16m 48s {color} | {color:green} The 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} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 49s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 83m 24s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 133m 17s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat |
| | org.apache.hadoop.hbase.mapreduce.TestSecureLoadIncrementalHFiles |
| |
[jira] [Commented] (HBASE-16866) Avoid NPE in AsyncRequestFutureImpl#updateStats
[
https://issues.apache.org/jira/browse/HBASE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584140#comment-15584140
]
Ted Yu commented on HBASE-16866:
{code}
980 if (stat == null) {
981 LOG.error("No found of any ClientProtos.RegionLoadStats from
server:" + server
{code}
Please correct syntax in log.
Modify description to replace NEP.
> Avoid NPE in AsyncRequestFutureImpl#updateStats
> ---
>
> Key: HBASE-16866
> URL: https://issues.apache.org/jira/browse/HBASE-16866
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16866.v0.patch
>
>
> If region disables the stats, it won’t response any
> ClientProtos.RegionLoadStats to client. So the NEP will happen in
> AsyncRequestFutureImpl#updateStats.
> We should use relevant log instead of NEP because the data manipulation
> shouldn’t be broken by statistics.
> {noformat}
> protected void updateStats(ServerName server, Map MultiResponse.RegionResult> results) {
> …
> ClientProtos.RegionLoadStats stat = regionStats.getValue().getStat();
> RegionLoadStats regionLoadstats =
> ProtobufUtil.createRegionLoadStats(stat);
> …
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16653) Backport HBASE-11393 to all branches which support namespace
[ https://issues.apache.org/jira/browse/HBASE-16653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584138#comment-15584138 ] Guanghao Zhang commented on HBASE-16653: [~chenheng] [~enis] Thanks all for reviewing. > Backport HBASE-11393 to all branches which support namespace > > > Key: HBASE-16653 > URL: https://issues.apache.org/jira/browse/HBASE-16653 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.0.5, 1.3.1, 0.98.22, 1.1.7, 1.2.4 >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 1.4.0 > > Attachments: HBASE-16653-branch-1-v1.patch, > HBASE-16653-branch-1-v2.patch, HBASE-16653-branch-1-v3.patch, > HBASE-16653-branch-1-v4.patch, HBASE-16653-branch-1-v4.patch, > HBASE-16653-branch-1-v5.patch > > > As HBASE-11386 mentioned, the parse code about replication table-cfs config > will be wrong when table name contains namespace and we can only config the > default namespace's tables in the peer. It is a bug for all branches which > support namespace. HBASE-11393 resolved this by use a pb object but it was > only merged to master branch. Other branches still have this problem. I > thought we should fix this bug in all branches which support namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16854) refactor the org.apache.hadoop.hbase.client.Action
[
https://issues.apache.org/jira/browse/HBASE-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584133#comment-15584133
]
Ted Yu commented on HBASE-16854:
{code}
26 public class TestAction {
{code}
Can the above be folded into existing test class ?
> refactor the org.apache.hadoop.hbase.client.Action
> --
>
> Key: HBASE-16854
> URL: https://issues.apache.org/jira/browse/HBASE-16854
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16854.v0.patch
>
>
> a) According to the previous comments, the Action doesn’t apply the generic.
> b) Action implements the Comparable, but the Action#compareTo cast the
> object to Action.
> For reasons outlined above, we should refactor the Action.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16866) Avoid NPE in AsyncRequestFutureImpl#updateStats
[
https://issues.apache.org/jira/browse/HBASE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584123#comment-15584123
]
Hadoop QA commented on HBASE-16866:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s
{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
2s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 14s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 15s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 17s {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} 0m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 15s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 55s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 35m 51s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833861/HBASE-16866.v0.patch |
| JIRA Issue | HBASE-16866 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 5d3f647d0525 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 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 / 10840a5 |
| Default Java | 1.8.0_101 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4062/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4062/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Avoid NPE in AsyncRequestFutureImpl#updateStats
> ---
>
> Key: HBASE-16866
> URL: https://issues.apache.org/jira/browse/HBASE-16866
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
>
[jira] [Commented] (HBASE-16326) CellModel / RowModel should override 'equals', 'hashCode' and 'toString'
[ https://issues.apache.org/jira/browse/HBASE-16326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584111#comment-15584111 ] Hudson commented on HBASE-16326: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1805 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1805/]) HBASE-16326 CellModel / RowModel should override 'equals', 'hashCode' (tedyu: rev 73e945670270de187be337037f75577ccc1a770b) * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/model/TestCellModel.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/CellModel.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/RowModel.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/model/TestRowModel.java > CellModel / RowModel should override 'equals', 'hashCode' and 'toString' > > > Key: HBASE-16326 > URL: https://issues.apache.org/jira/browse/HBASE-16326 > Project: HBase > Issue Type: Bug > Components: REST >Reporter: Minwoo Kang >Assignee: Minwoo Kang >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-16326.master.001.patch > > > I create two RowModel. > Each RowModel have same value. > But RowModel does not override 'equals'. > So 'rowModel1.equals(rowModel2)' is false. > And While run System.out.println(rowModel), print > 'org.apache.hadoop.hbase.rest.model.RowModel@44019852' in console -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16855) Avoid NPE in MetricsConnection’s construction
[
https://issues.apache.org/jira/browse/HBASE-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584110#comment-15584110
]
Hudson commented on HBASE-16855:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1805 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1805/])
HBASE-16855 Avoid NPE in MetricsConnection’s construction (ChiaPing (tedyu: rev
c8e9a295c133ef9507a84ab9c70d18563e2c22ad)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/MetricsConnection.java
* (edit)
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestMetricsConnection.java
> Avoid NPE in MetricsConnection’s construction
> -
>
> Key: HBASE-16855
> URL: https://issues.apache.org/jira/browse/HBASE-16855
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16855.branch-1.v0.patch, HBASE-16855.v0.patch,
> HBASE-16855.v1.patch
>
>
> a) The batch pool may not be assigned a value in the ConnectionImpl’s
> construction.
> b) The meta pool always be null in the ConnectionImpl’s construction.
> For reasons outlined above, the NPE may happen in MetricsConnection’s
> construction
> {noformat}
> final ThreadPoolExecutor batchPool = (ThreadPoolExecutor)
> conn.getCurrentBatchPool();
> final ThreadPoolExecutor metaPool = (ThreadPoolExecutor)
> conn.getCurrentMetaLookupPool();
> this.registry.register(name(this.getClass(), "executorPoolActiveThreads",
> scope),
> new RatioGauge() {
> @Override
> protected Ratio getRatio() {
> return Ratio.of(batchPool.getActiveCount(),
> batchPool.getMaximumPoolSize());
> }
> });
> this.registry.register(name(this.getClass(), "metaPoolActiveThreads",
> scope),
> new RatioGauge() {
> @Override
> protected Ratio getRatio() {
> return Ratio.of(metaPool.getActiveCount(),
> metaPool.getMaximumPoolSize());
> }
> });
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16856) Exception message in SyncRunner.run() should print currentSequence
[
https://issues.apache.org/jira/browse/HBASE-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584109#comment-15584109
]
Hudson commented on HBASE-16856:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1805 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1805/])
HBASE-16856 Exception message in SyncRunner.run() should print (tedyu: rev
278625312047a2100f4dbb2d2eaa4e2219d00e14)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
> Exception message in SyncRunner.run() should print currentSequence
> --
>
> Key: HBASE-16856
> URL: https://issues.apache.org/jira/browse/HBASE-16856
> Project: HBase
> Issue Type: Bug
> Components: wal
>Affects Versions: 2.0.0, 1.2.2, 1.1.7
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16856.patch
>
>
> A very small bug, a typo in exception message:
> {code}
> if (syncFutureSequence > currentSequence) {
> throw new IllegalStateException("currentSequence=" +
> syncFutureSequence
> + ", syncFutureSequence=" + syncFutureSequence);
> }
> {code}
> It should print currentSequence and syncFutureSequence, but print two
> syncFutureSequence
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16846) Procedure v2 - executor cleanup
[ https://issues.apache.org/jira/browse/HBASE-16846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584108#comment-15584108 ] Hudson commented on HBASE-16846: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1805 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1805/]) HBASE-16846 Procedure v2 - executor cleanup (matteo.bertozzi: rev c6e9dabe625b910b3b140d9234710f6e8b968b37) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMasterProcedureScheduler.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMasterProcedureSchedulerConcurrency.java * (add) hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/util/DelayedUtil.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * (edit) hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/Procedure.java * (edit) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestProcedureInMemoryChore.java * (edit) hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/AbstractProcedureScheduler.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureEnv.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureScheduler.java * (edit) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/ProcedureTestingUtility.java * (add) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/util/TestDelayedUtil.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureSchedulerPerformanceEvaluation.java * (edit) hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/ProcedureExecutor.java * (add) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestProcedureExecutor.java > Procedure v2 - executor cleanup > --- > > Key: HBASE-16846 > URL: https://issues.apache.org/jira/browse/HBASE-16846 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16846-v0.patch > > > Trying to reorganize the executor. move some code around grouping common > code, remove some synchronization from Procedure and adding comments on > various sections. > the execution logic remains unchanged -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16145) MultiRowRangeFilter constructor shouldn't throw IOException
[ https://issues.apache.org/jira/browse/HBASE-16145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16145: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Thanks for the patch, Konstantin > MultiRowRangeFilter constructor shouldn't throw IOException > --- > > Key: HBASE-16145 > URL: https://issues.apache.org/jira/browse/HBASE-16145 > Project: HBase > Issue Type: Wish >Reporter: Konstantin Ryakhovskiy >Assignee: Konstantin Ryakhovskiy >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16145.master.001.patch, > HBASE-16145.master.002.patch > > > MultiRowRangeFilter constructor declares IOException. > The constructor: > - sorts and merges incoming arguments - list of ranges, > - assigns sorted list to a private variable and does not do anything else. > There is no reason to declare IOException. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16283) Batch Append/Increment will always fail if set ReturnResults to false
[
https://issues.apache.org/jira/browse/HBASE-16283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-16283:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch, Allan.
> Batch Append/Increment will always fail if set ReturnResults to false
> -
>
> Key: HBASE-16283
> URL: https://issues.apache.org/jira/browse/HBASE-16283
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0.0, 1.1.5, 1.2.2
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: FailedCase.java, HBASE-16283.patch, HBASE-16283v2.patch,
> HBASE-16283v3.patch
>
>
> If set Append/Increment's ReturnResult attribute to false, and batch the
> appends/increments to server. The batch operation will always return false.
> The reason is that, since return result is set to false, append/increment
> will return null instead of Result object. But in
> ResponseConverter#getResults, there is some check code
> {code}
> if (requestRegionActionCount != responseRegionActionResultCount) {
> throw new IllegalStateException("Request mutation count=" +
> requestRegionActionCount +
> " does not match response mutation result count=" +
> responseRegionActionResultCount);
> }
> {code}
> That means if the result count is not meet with request mutation count, it
> will fail the request.
> The solution is simple, instead of returning a null result, returning a empty
> result if ReturnResult set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-16283) Batch Append/Increment will always fail if set ReturnResults to false
[
https://issues.apache.org/jira/browse/HBASE-16283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-16283:
--
Assignee: Allan Yang
> Batch Append/Increment will always fail if set ReturnResults to false
> -
>
> Key: HBASE-16283
> URL: https://issues.apache.org/jira/browse/HBASE-16283
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0.0, 1.1.5, 1.2.2
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: FailedCase.java, HBASE-16283.patch, HBASE-16283v2.patch,
> HBASE-16283v3.patch
>
>
> If set Append/Increment's ReturnResult attribute to false, and batch the
> appends/increments to server. The batch operation will always return false.
> The reason is that, since return result is set to false, append/increment
> will return null instead of Result object. But in
> ResponseConverter#getResults, there is some check code
> {code}
> if (requestRegionActionCount != responseRegionActionResultCount) {
> throw new IllegalStateException("Request mutation count=" +
> requestRegionActionCount +
> " does not match response mutation result count=" +
> responseRegionActionResultCount);
> }
> {code}
> That means if the result count is not meet with request mutation count, it
> will fail the request.
> The solution is simple, instead of returning a null result, returning a empty
> result if ReturnResult set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16864) Procedure v2 - Fix StateMachineProcedure support for child procs at last step
[
https://issues.apache.org/jira/browse/HBASE-16864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583687#comment-15583687
]
Hadoop QA commented on HBASE-16864:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s
{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: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
3s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 10s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 11s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 11s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 44s {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} 0m
7s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 13s
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 36m 7s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:7bda515 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833811/HBASE-16864-v0.patch |
| JIRA Issue | HBASE-16864 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux b4c969fdd569 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 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 / 73e9456 |
| Default Java | 1.8.0_101 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4057/testReport/ |
| modules | C: hbase-procedure U: hbase-procedure |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4057/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Procedure v2 - Fix StateMachineProcedure support for child procs at last step
> -
>
> Key: HBASE-16864
> URL: https://issues.apache.org/jira/browse/HBASE-16864
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 2.0.0
>
>
[jira] [Commented] (HBASE-16824) Writer.flush() can be called on already closed streams in WAL roll
[
https://issues.apache.org/jira/browse/HBASE-16824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583685#comment-15583685
]
Enis Soztutar commented on HBASE-16824:
---
There is a deadlock happening with this it seems:
Some threads are like this:
{code}
"22" #222 daemon prio=5 os_prio=31 tid=0x7fd2063e1800 nid=0x19403 in
Object.wait() [0x7f373000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at
org.apache.hadoop.hbase.regionserver.wal.SyncFuture.get(SyncFuture.java:159)
- locked <0x0006c45563d8> (a
org.apache.hadoop.hbase.regionserver.wal.SyncFuture)
at
org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.blockOnSync(AbstractFSWAL.java:641)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog.publishSyncThenBlockOnCompletion(FSHLog.java:765)
at org.apache.hadoop.hbase.regionserver.wal.FSHLog.sync(FSHLog.java:807)
at
org.apache.hadoop.hbase.regionserver.wal.TestLogRollingNoCluster$Appender.run(TestLogRollingNoCluster.java:168)
{code}
Others:
{code}
"21" #221 daemon prio=5 os_prio=31 tid=0x7fd205fe7800 nid=0x19203 waiting
on condition [0x7f27]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0006c442d150> (a
java.util.concurrent.locks.ReentrantLock$FairSync)
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.acquireQueued(AbstractQueuedSynchronizer.java:870)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at
java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at
org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.rollWriter(AbstractFSWAL.java:664)
at
org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.rollWriter(AbstractFSWAL.java:426)
at
org.apache.hadoop.hbase.regionserver.wal.TestLogRollingNoCluster$Appender.run(TestLogRollingNoCluster.java:153)
{code}
Syncers:
{code}
"sync.4" #198 daemon prio=5 os_prio=31 tid=0x7fd20a231800 nid=0x16603
waiting on condition [0x7dc2e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0006c4598028> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog$SyncRunner.run(FSHLog.java:609)
at java.lang.Thread.run(Thread.java:745)
{code}
and the RBEH:
{code}
"Time-limited test.append-pool1-t1" #199 daemon prio=5 os_prio=31
tid=0x7fd207f54000 nid=0x15c03 in Object.wait() [0x7d71f000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:460)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.attainSafePoint(FSHLog.java:1129)
- locked <0x0006c45af270> (a java.lang.Object)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:1095)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:946)
at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Trying to understand how come this happens. Will report back.
> Writer.flush() can be called on already closed streams in WAL roll
> --
>
> Key: HBASE-16824
> URL: https://issues.apache.org/jira/browse/HBASE-16824
> Project: HBase
> Issue Type: Bug
>Reporter: Atri Sharma
>Assignee: Enis Soztutar
> Attachments: hbase-16824_v1.patch
>
>
> In https://issues.apache.org/jira/browse/HBASE-12074, we hit an error if an
> async thread calls flush on a WAL record already closed as the WAL is being
> rotated. This JIRA investigates if setting the new WAL record path as the
> first operation
[jira] [Updated] (HBASE-16865) Procedure v2 - Inherit lock from root proc
[ https://issues.apache.org/jira/browse/HBASE-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-16865: Status: Patch Available (was: Open) > Procedure v2 - Inherit lock from root proc > -- > > Key: HBASE-16865 > URL: https://issues.apache.org/jira/browse/HBASE-16865 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-16865-v0.patch > > > At the moment we support inheriting locks from the parent procedure for a 2 > level procedures, but in case of reopen table regions we have a 3 level > procedures (ModifyTable -> ReOpen -> [Unassign/Assign]) and reopen does not > have any locks on its own. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16865) Procedure v2 - Inherit lock from root proc
[ https://issues.apache.org/jira/browse/HBASE-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-16865: Attachment: HBASE-16865-v0.patch > Procedure v2 - Inherit lock from root proc > -- > > Key: HBASE-16865 > URL: https://issues.apache.org/jira/browse/HBASE-16865 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-16865-v0.patch > > > At the moment we support inheriting locks from the parent procedure for a 2 > level procedures, but in case of reopen table regions we have a 3 level > procedures (ModifyTable -> ReOpen -> [Unassign/Assign]) and reopen does not > have any locks on its own. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16600) [0.98] ReplicationAdminTest occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-16600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583496#comment-15583496
]
Ted Yu commented on HBASE-16600:
Adding more log revealed the following:
{code}
2016-10-17 21:10:13,184 WARN [main] replication.ReplicationPeersZKImpl(153):
cannot remove
org.apache.zookeeper.KeeperException$NotEmptyException: KeeperErrorCode =
Directory not empty for /hbase/replication/peers/1
at org.apache.zookeeper.KeeperException.create(KeeperException.java:125)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:873)
at
org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.delete(RecoverableZooKeeper.java:178)
at
org.apache.hadoop.hbase.zookeeper.ZKUtil.deleteNodeFailSilent(ZKUtil.java:1265)
at
org.apache.hadoop.hbase.zookeeper.ZKUtil.processSequentially(ZKUtil.java:1709)
at
org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1698)
at
org.apache.hadoop.hbase.zookeeper.ZKUtil.deleteNodeRecursivelyMultiOrSequential(ZKUtil.java:1416)
at
org.apache.hadoop.hbase.zookeeper.ZKUtil.deleteNodeRecursively(ZKUtil.java:1283)
at
org.apache.hadoop.hbase.replication.ReplicationPeersZKImpl.removePeer(ReplicationPeersZKImpl.java:151)
at
org.apache.hadoop.hbase.client.replication.ReplicationAdmin.removePeer(ReplicationAdmin.java:229)
{code}
> [0.98] ReplicationAdminTest occasionally fails
> --
>
> Key: HBASE-16600
> URL: https://issues.apache.org/jira/browse/HBASE-16600
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Priority: Minor
> Attachments: 16600-testShell-output.txt
>
>
> When testing 0.98.22 RC, I saw the following test failure:
> {code}
> 1) Error:
> test_add_peer:_single_zk_cluster_key(Hbase::ReplicationAdminTest):
> NativeException: org.apache.hadoop.hbase.replication.ReplicationException:
> Could not remove peer with id=1
> org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java:153:in
> `removePeer'
> org/apache/hadoop/hbase/client/replication/ReplicationAdmin.java:229:in
> `removePeer'
>
> /mnt/disk2/a/hbase-0.98.22/hbase-shell/src/main/ruby/hbase/replication_admin.rb:102:in
> `remove_peer'
> ./src/test/ruby/hbase/replication_admin_test.rb:84:in
> `test_add_peer:_single_zk_cluster_key'
> org/jruby/RubyProc.java:270:in `call'
> org/jruby/RubyKernel.java:2105:in `send'
> org/jruby/RubyArray.java:1620:in `each'
> org/jruby/RubyArray.java:1620:in `each'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12894) Upgrade Jetty to 9.2.6
[ https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583458#comment-15583458 ] stack commented on HBASE-12894: --- [~busbey] Thanks Sean. Was thinking more server-side where there'd be our jetty and hadoops on same CLASSPATH. Then we'd have to versions of these libs (hadoop3 is on old jetty at least at mo...) Let me see what next run is like. If decent, will commit. > Upgrade Jetty to 9.2.6 > -- > > Key: HBASE-12894 > URL: https://issues.apache.org/jira/browse/HBASE-12894 > Project: HBase > Issue Type: Improvement > Components: REST, UI >Affects Versions: 0.98.0 >Reporter: Rick Hallihan >Assignee: Guang Yang >Priority: Critical > Labels: MicrosoftSupport > Fix For: 2.0.0 > > Attachments: HBASE-12894_Jetty9_v0.patch, > HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch > > > The Jetty component that is used for the HBase Stargate REST endpoint is > version 6.1.26 and is fairly outdated. We recently had a customer inquire > about enabling cross-origin resource sharing (CORS) for the REST endpoint and > found that this older version does not include the necessary filter or > configuration options, highlighted at: > http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter > The Jetty project has had significant updates through versions 7, 8 and 9, > including a transition to be an Eclipse subproject, so updating to the latest > version may be non-trivial. The last update to the Jetty component in > https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update > and did not require significant work. This update will include a package > namespace update so there will likely be a larger number of required changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16863) Move Backup constants from HConstants to BackupRestoreConstants
Vladimir Rodionov created HBASE-16863: - Summary: Move Backup constants from HConstants to BackupRestoreConstants Key: HBASE-16863 URL: https://issues.apache.org/jira/browse/HBASE-16863 Project: HBase Issue Type: Sub-task Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12894) Upgrade Jetty to 9.2.6
[ https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583420#comment-15583420 ] Sean Busbey commented on HBASE-12894: - the tests are probably not a concern, though we should verify they pass locally and/or are on the flakey list. the findbugs concerns will need to get addressed. I'm in favor of library bumps in major versions. What kind of breakage are you worried about [~stack]? I thought in HBase 2 we were going to really push for folks to use the hbase-shaded-client instead of the regular one? That just leaves coprocessors impacted, I think? Release notes for the libraries we update should suffice for that crowd, I'd think. > Upgrade Jetty to 9.2.6 > -- > > Key: HBASE-12894 > URL: https://issues.apache.org/jira/browse/HBASE-12894 > Project: HBase > Issue Type: Improvement > Components: REST, UI >Affects Versions: 0.98.0 >Reporter: Rick Hallihan >Assignee: Guang Yang >Priority: Critical > Labels: MicrosoftSupport > Fix For: 2.0.0 > > Attachments: HBASE-12894_Jetty9_v0.patch, > HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch > > > The Jetty component that is used for the HBase Stargate REST endpoint is > version 6.1.26 and is fairly outdated. We recently had a customer inquire > about enabling cross-origin resource sharing (CORS) for the REST endpoint and > found that this older version does not include the necessary filter or > configuration options, highlighted at: > http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter > The Jetty project has had significant updates through versions 7, 8 and 9, > including a transition to be an Eclipse subproject, so updating to the latest > version may be non-trivial. The last update to the Jetty component in > https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update > and did not require significant work. This update will include a package > namespace update so there will likely be a larger number of required changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16608) Introducing the ability to merge ImmutableSegments without copy-compaction or SQM usage
[ https://issues.apache.org/jira/browse/HBASE-16608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583413#comment-15583413 ] stack commented on HBASE-16608: --- You should do it [~ebortnik]. Your words! > Introducing the ability to merge ImmutableSegments without copy-compaction or > SQM usage > --- > > Key: HBASE-16608 > URL: https://issues.apache.org/jira/browse/HBASE-16608 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-16417-V02.patch, HBASE-16417-V04.patch, > HBASE-16417-V06.patch, HBASE-16417-V07.patch, HBASE-16417-V08.patch, > HBASE-16417-V10.patch, HBASE-16608-V01.patch, HBASE-16608-V03.patch, > HBASE-16608-V04.patch, HBASE-16608-V08.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12894) Upgrade Jetty to 9.2.6
[ https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12894: -- Attachment: HBASE-12894_Jetty9_v1.patch Retry to see if repeatable UT faiilures. > Upgrade Jetty to 9.2.6 > -- > > Key: HBASE-12894 > URL: https://issues.apache.org/jira/browse/HBASE-12894 > Project: HBase > Issue Type: Improvement > Components: REST, UI >Affects Versions: 0.98.0 >Reporter: Rick Hallihan >Assignee: Guang Yang >Priority: Critical > Labels: MicrosoftSupport > Fix For: 2.0.0 > > Attachments: HBASE-12894_Jetty9_v0.patch, > HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch > > > The Jetty component that is used for the HBase Stargate REST endpoint is > version 6.1.26 and is fairly outdated. We recently had a customer inquire > about enabling cross-origin resource sharing (CORS) for the REST endpoint and > found that this older version does not include the necessary filter or > configuration options, highlighted at: > http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter > The Jetty project has had significant updates through versions 7, 8 and 9, > including a transition to be an Eclipse subproject, so updating to the latest > version may be non-trivial. The last update to the Jetty component in > https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update > and did not require significant work. This update will include a package > namespace update so there will likely be a larger number of required changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-16849) Document for HBASE-14918 (in-memory flushes/compactions)
[ https://issues.apache.org/jira/browse/HBASE-16849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-16849. --- Resolution: Duplicate Resolving s duplicate of HBASE-16851 > Document for HBASE-14918 (in-memory flushes/compactions) > > > Key: HBASE-16849 > URL: https://issues.apache.org/jira/browse/HBASE-16849 > Project: HBase > Issue Type: Sub-task >Reporter: Devaraj Das >Assignee: Anastasia Braginsky >Priority: Blocker > > As discussed here - > https://issues.apache.org/jira/browse/HBASE-16608?focusedCommentId=15577213=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15577213 > [~stack] [~anoop.hbase] [~ram_krish] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16733) add hadoop 3.0.0-alpha1 to precommit checks
[ https://issues.apache.org/jira/browse/HBASE-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583381#comment-15583381 ] Sean Busbey commented on HBASE-16733: - +1, conditioned on HBASE-16712. > add hadoop 3.0.0-alpha1 to precommit checks > --- > > Key: HBASE-16733 > URL: https://issues.apache.org/jira/browse/HBASE-16733 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: 2.0.0 > > Attachments: hbase-16733.v0.patch > > > Been working on getting hadoop3 related build up and running and woudl ike to > add a precommit check so that new commits don't break the mvn compile/install. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16608) Introducing the ability to merge ImmutableSegments without copy-compaction or SQM usage
[ https://issues.apache.org/jira/browse/HBASE-16608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583313#comment-15583313 ] Edward Bortnikov commented on HBASE-16608: -- Definitely. Please do whatever facilitates progress. Thanks [~stack]! > Introducing the ability to merge ImmutableSegments without copy-compaction or > SQM usage > --- > > Key: HBASE-16608 > URL: https://issues.apache.org/jira/browse/HBASE-16608 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-16417-V02.patch, HBASE-16417-V04.patch, > HBASE-16417-V06.patch, HBASE-16417-V07.patch, HBASE-16417-V08.patch, > HBASE-16417-V10.patch, HBASE-16608-V01.patch, HBASE-16608-V03.patch, > HBASE-16608-V04.patch, HBASE-16608-V08.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16774) [shell] Add coverage to TestShell when ZooKeeper is not reachable
[ https://issues.apache.org/jira/browse/HBASE-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583308#comment-15583308 ] Esteban Gutierrez commented on HBASE-16774: --- TestRSStatusServlet has been flakey for a while and if I run the tests locally TestRSStatusServlet doesn't fail. > [shell] Add coverage to TestShell when ZooKeeper is not reachable > - > > Key: HBASE-16774 > URL: https://issues.apache.org/jira/browse/HBASE-16774 > Project: HBase > Issue Type: Improvement > Components: shell, test >Reporter: Esteban Gutierrez >Assignee: Esteban Gutierrez > Attachments: > 0001-HBASE-16774-shell-Add-coverage-to-TestShell-when-Zoo.patch, > 0001-HBASE-16774-shell-Add-coverage-to-TestShell-when-Zoo.patch, > HBASE-16774.001.patch, HBASE-16774.002.patch > > > While testing a couple of things in master I noticed that after some of the > changes done in HBASE-16117 the hbase shell would die when there is no > ZooKeeper server up or if we get another ZK exception. This is to add > coverage to test the shell when ZK is not up or if we get another exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16847) comment out broken test-compile references
[ https://issues.apache.org/jira/browse/HBASE-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583264#comment-15583264 ] Sean Busbey commented on HBASE-16847: - (I removed the release note because I'm presuming this change will effectively be undone before we merge) > comment out broken test-compile references > -- > > Key: HBASE-16847 > URL: https://issues.apache.org/jira/browse/HBASE-16847 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Sean Busbey >Assignee: Umesh Agashe > Fix For: hbase-14439 > > Attachments: HBASE-16487-hbase-14439.v1.patch > > > so that we can track incremental progress on making test-compile pass, > comment out existing failures and document (here) the number of test files > with such commented out area. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16847) comment out broken test-compile references
[ https://issues.apache.org/jira/browse/HBASE-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-16847: Release Note: (was: Commented out broken test-compile references. These will be fixed and put back in later. Command 'mvn package -DskipTests' should work with these changes.) > comment out broken test-compile references > -- > > Key: HBASE-16847 > URL: https://issues.apache.org/jira/browse/HBASE-16847 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Sean Busbey >Assignee: Umesh Agashe > Fix For: hbase-14439 > > Attachments: HBASE-16487-hbase-14439.v1.patch > > > so that we can track incremental progress on making test-compile pass, > comment out existing failures and document (here) the number of test files > with such commented out area. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16754) Regions failing compaction due to referencing non-existent store file
[
https://issues.apache.org/jira/browse/HBASE-16754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583239#comment-15583239
]
Gary Helmling commented on HBASE-16754:
---
The 4 timed out tests all pass for me locally.
> Regions failing compaction due to referencing non-existent store file
> -
>
> Key: HBASE-16754
> URL: https://issues.apache.org/jira/browse/HBASE-16754
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.3
>Reporter: Gary Helmling
>Assignee: Gary Helmling
>Priority: Blocker
> Fix For: 1.3.0
>
> Attachments: HBASE-16754.001.patch
>
>
> Running a mixed read write workload on a recent build off branch-1.3, we are
> seeing compactions occasionally fail with errors like the following (actual
> filenames replaced with placeholders):
> {noformat}
> 16/09/27 16:57:28 ERROR regionserver.CompactSplitThread: Compaction selection
> failed Store = XXX, pri = 116
> java.io.FileNotFoundException: File does not exist:
> hdfs://.../hbase/data/ns/table/region/cf/XXfilenameXX
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1309)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1301)
> at
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1317)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:421)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getReferencedFileStatus(StoreFileInfo.java:342)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getFileStatus(StoreFileInfo.java:355)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getModificationTime(StoreFileInfo.java:360)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile.getModificationTimeStamp(StoreFile.java:321)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreUtils.getLowestTimestamp(StoreUtils.java:63)
> at
> org.apache.hadoop.hbase.regionserver.compactions.RatioBasedCompactionPolicy.shouldPerformMajorCompaction(RatioBasedCompactionPolicy.java:63)
> at
> org.apache.hadoop.hbase.regionserver.compactions.SortedCompactionPolicy.selectCompaction(SortedCompactionPolicy.java:82)
>
> at
> org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.select(DefaultStoreEngine.java:107)
>
> at
> org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(HStore.java:1644)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread.selectCompaction(CompactSplitThread.java:373)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread.access$100(CompactSplitThread.java:59)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.doCompaction(CompactSplitThread.java:498)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.run(CompactSplitThread.java:568)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 16/09/27 17:01:31 ERROR regionserver.CompactSplitThread: Compaction selection
> failed Store = XXX, pri = 115
> java.io.FileNotFoundException: File does not exist:
> hdfs://.../hbase/data/ns/table/region/cf/XXfilenameXX
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1309)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1301)
> at
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1317)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:421)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getReferencedFileStatus(StoreFileInfo.java:342)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getFileStatus(StoreFileInfo.java:355)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getModificationTime(StoreFileInfo.java:360)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile.getModificationTimeStamp(StoreFile.java:321)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreUtils.getLowestTimestamp(StoreUtils.java:63)
> at
>
[jira] [Updated] (HBASE-16465) Disable region splits and merges, balancer during full backup
[ https://issues.apache.org/jira/browse/HBASE-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16465: --- Status: Open (was: Patch Available) > Disable region splits and merges, balancer during full backup > - > > Key: HBASE-16465 > URL: https://issues.apache.org/jira/browse/HBASE-16465 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Attachments: HBASE-16465-v1.patch, HBASE-16465-v2.patch, > HBASE-16465-v3.patch, HBASE-16465-v4.patch, HBASE-16465-v5.patch, > HBASE-16465-v6.patch > > > Incorporate HBASE-15128 > Balancer, catalog janitor and region normalizer should be disabled as well > during full backup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16326) CellModel / RowModel should override 'equals', 'hashCode' and 'toString'
[ https://issues.apache.org/jira/browse/HBASE-16326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16326: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Thanks for the patch, Minwoo > CellModel / RowModel should override 'equals', 'hashCode' and 'toString' > > > Key: HBASE-16326 > URL: https://issues.apache.org/jira/browse/HBASE-16326 > Project: HBase > Issue Type: Bug > Components: REST >Reporter: Minwoo Kang >Assignee: Minwoo Kang >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-16326.master.001.patch > > > I create two RowModel. > Each RowModel have same value. > But RowModel does not override 'equals'. > So 'rowModel1.equals(rowModel2)' is false. > And While run System.out.println(rowModel), print > 'org.apache.hadoop.hbase.rest.model.RowModel@44019852' in console -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16326) CellModel / RowModel should override 'equals', 'hashCode' and 'toString'
[ https://issues.apache.org/jira/browse/HBASE-16326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16326: --- Summary: CellModel / RowModel should override 'equals', 'hashCode' and 'toString' (was: RowModel does not override 'equals', 'hashCode' and 'toString' (with CellModel)) > CellModel / RowModel should override 'equals', 'hashCode' and 'toString' > > > Key: HBASE-16326 > URL: https://issues.apache.org/jira/browse/HBASE-16326 > Project: HBase > Issue Type: Bug > Components: REST >Reporter: Minwoo Kang >Assignee: Minwoo Kang >Priority: Trivial > Attachments: HBASE-16326.master.001.patch > > > I create two RowModel. > Each RowModel have same value. > But RowModel does not override 'equals'. > So 'rowModel1.equals(rowModel2)' is false. > And While run System.out.println(rowModel), print > 'org.apache.hadoop.hbase.rest.model.RowModel@44019852' in console -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16621) HBCK should have -fixHFileLinks
[
https://issues.apache.org/jira/browse/HBASE-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583215#comment-15583215
]
Ted Yu commented on HBASE-16621:
{code}
+return isFile(fs, isDir, p);
+ } catch (IOException ioe) {
+// Maybe the file was moved or the fs was disconnected.
+LOG.warn("Skipping file " + p + " due to IOException", ioe);
+return false;
{code}
Is the above safe to do ? See HBASE-16527
> HBCK should have -fixHFileLinks
> ---
>
> Key: HBASE-16621
> URL: https://issues.apache.org/jira/browse/HBASE-16621
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Janos Gub
> Labels: beginner, operability
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16621.patch, refactor-2.patch
>
>
> Similar to {{-fixReferenceFiles}}, HBCK should be able to sideline dangling
> HFile Links as well.
> We have seen a couple of cases, where due to HDFS-level fsck run which
> deleted files with missing blocks, the cluster is left with dangling HFIle
> Links, and regions cannot be opened because of these. Only a manual and
> error-prone finding and clearing of HFileLinks can save the tables regions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16712) fix hadoop-3.0 profile mvn install
[ https://issues.apache.org/jira/browse/HBASE-16712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583213#comment-15583213 ] Sean Busbey commented on HBASE-16712: - +1. Once this goes in, I'd like to make a follow on to switch from including a supplemental entry for Xerces to skipping it in LICENSE/NOTICE since we know it's not actually bundled. > fix hadoop-3.0 profile mvn install > -- > > Key: HBASE-16712 > URL: https://issues.apache.org/jira/browse/HBASE-16712 > Project: HBase > Issue Type: Bug > Components: build, hadoop3 >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: 2.0.0 > > Attachments: h2-deps, h3-deps, hbase-16712.v0.patch, > hbase-16712.v1.patch, hbase-16712.v2.patch, hbase-16712.v3.patch > > > After the compile is fixed, mvn install fails due to transitive dependencies > coming from hadoop3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16861) Rename Service to Task
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16861: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Thanks Vlad for the patch > Rename Service to Task > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-16861-v1.patch, HBASE-16861-v2.patch > > > Rename BackupCopyService and RestoreServive to xxxTask. They are not services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16789) Remove directory layout/ filesystem references from CompactionTool
[
https://issues.apache.org/jira/browse/HBASE-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583108#comment-15583108
]
Hadoop QA commented on HBASE-16789:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s
{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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 23s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
26s {color} | {color:green} hbase-14439 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 52s
{color} | {color:green} hbase-14439 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s {color} | {color:green} hbase-14439 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
21s {color} | {color:green} hbase-14439 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 39s
{color} | {color:red} hbase-server in hbase-14439 has 5 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 0s
{color} | {color:green} hbase-14439 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 7s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 53s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 53s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 27s {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
23s {color} | {color:green} the patch passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 50s
{color} | {color:red} hbase-server generated 1 new + 4 unchanged - 1 fixed = 5
total (was 5) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 29s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 14m 9s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 20m 49s {color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 88m 30s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Dead store to conf in
org.apache.hadoop.hbase.regionserver.CompactionTool.run(String[]) At
CompactionTool.java:org.apache.hadoop.hbase.regionserver.CompactionTool.run(String[])
At CompactionTool.java:[line 221] |
| Failed junit tests | hadoop.hbase.filter.TestDependentColumnFilter |
| | hadoop.hbase.snapshot.TestMobRestoreSnapshotHelper |
| | hadoop.hbase.coprocessor.TestCoprocessorInterface |
| | hadoop.hbase.coprocessor.TestRegionObserverStacking |
| | hadoop.hbase.filter.TestFilter |
| |
[jira] [Updated] (HBASE-16861) Rename Service to Task
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16861: --- Summary: Rename Service to Task (was: xxxService refactoring) > Rename Service to Task > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16861-v1.patch, HBASE-16861-v2.patch > > > Rename BackupCopyService and RestoreServive to xxxTask. They are not services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16861) xxxService refactoring
[
https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583087#comment-15583087
]
Hadoop QA commented on HBASE-16861:
---
| (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:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s {color}
| {color:red} HBASE-16861 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833779/HBASE-16861-v2.patch |
| JIRA Issue | HBASE-16861 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4055/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> xxxService refactoring
> --
>
> Key: HBASE-16861
> URL: https://issues.apache.org/jira/browse/HBASE-16861
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Attachments: HBASE-16861-v1.patch, HBASE-16861-v2.patch
>
>
> Rename BackupCopyService and RestoreServive to xxxTask. They are not services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16774) [shell] Add coverage to TestShell when ZooKeeper is not reachable
[ https://issues.apache.org/jira/browse/HBASE-16774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583074#comment-15583074 ] Jonathan Hsieh commented on HBASE-16774: Hey [~esteban], is the TestRSStatusServlet failure here legit or is it a flaky? > [shell] Add coverage to TestShell when ZooKeeper is not reachable > - > > Key: HBASE-16774 > URL: https://issues.apache.org/jira/browse/HBASE-16774 > Project: HBase > Issue Type: Improvement > Components: shell, test >Reporter: Esteban Gutierrez >Assignee: Esteban Gutierrez > Attachments: > 0001-HBASE-16774-shell-Add-coverage-to-TestShell-when-Zoo.patch, > 0001-HBASE-16774-shell-Add-coverage-to-TestShell-when-Zoo.patch, > HBASE-16774.001.patch, HBASE-16774.002.patch > > > While testing a couple of things in master I noticed that after some of the > changes done in HBASE-16117 the hbase shell would die when there is no > ZooKeeper server up or if we get another ZK exception. This is to add > coverage to test the shell when ZK is not up or if we get another exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16712) fix hadoop-3.0 profile mvn install
[ https://issues.apache.org/jira/browse/HBASE-16712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583067#comment-15583067 ] Jonathan Hsieh commented on HBASE-16712: Will fix whitespaces on commit. Tests shouldn't be affected by this patch. TestAdmin2, TestSnapshotCloneIndependence are on the flaky page. TestHCM was flakey for me locally, but I don't see how this would affect it. > fix hadoop-3.0 profile mvn install > -- > > Key: HBASE-16712 > URL: https://issues.apache.org/jira/browse/HBASE-16712 > Project: HBase > Issue Type: Bug > Components: build, hadoop3 >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: 2.0.0 > > Attachments: h2-deps, h3-deps, hbase-16712.v0.patch, > hbase-16712.v1.patch, hbase-16712.v2.patch, hbase-16712.v3.patch > > > After the compile is fixed, mvn install fails due to transitive dependencies > coming from hadoop3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16861) xxxService refactoring
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16861: -- Status: Patch Available (was: Open) > xxxService refactoring > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16861-v1.patch, HBASE-16861-v2.patch > > > Rename BackupCopyService and RestoreServive to xxxTask. They are not services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16861) xxxService refactoring
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16861: -- Attachment: HBASE-16861-v2.patch v2. Cosmetic fixes. > xxxService refactoring > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16861-v1.patch, HBASE-16861-v2.patch > > > Rename BackupCopyService and RestoreServive to xxxTask. They are not services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16861) xxxService refactoring
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16861: -- Description: Rename BackupCopyService and RestoreServive to xxxTask. They are not services. (was: Rename BackupCopyService and RestoreServive to xxxOperation. They are not services.) > xxxService refactoring > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16861-v1.patch > > > Rename BackupCopyService and RestoreServive to xxxTask. They are not services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16754) Regions failing compaction due to referencing non-existent store file
[
https://issues.apache.org/jira/browse/HBASE-16754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583023#comment-15583023
]
Gary Helmling commented on HBASE-16754:
---
[~ram_krish], yes, the same problem is present in branch-1.2 -- we drop the
compaction WAL entry on splitting there as well. However, as you mention, in
1.2 the compacted files are archived on compaction completion. I believe this
significantly narrows the window where we can hit this vs. in 1.3+, where
archiving happens asynchronously via CompactedHFilesDischarger.
> Regions failing compaction due to referencing non-existent store file
> -
>
> Key: HBASE-16754
> URL: https://issues.apache.org/jira/browse/HBASE-16754
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.3
>Reporter: Gary Helmling
>Assignee: Gary Helmling
>Priority: Blocker
> Fix For: 1.3.0
>
> Attachments: HBASE-16754.001.patch
>
>
> Running a mixed read write workload on a recent build off branch-1.3, we are
> seeing compactions occasionally fail with errors like the following (actual
> filenames replaced with placeholders):
> {noformat}
> 16/09/27 16:57:28 ERROR regionserver.CompactSplitThread: Compaction selection
> failed Store = XXX, pri = 116
> java.io.FileNotFoundException: File does not exist:
> hdfs://.../hbase/data/ns/table/region/cf/XXfilenameXX
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1309)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1301)
> at
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1317)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:421)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getReferencedFileStatus(StoreFileInfo.java:342)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getFileStatus(StoreFileInfo.java:355)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getModificationTime(StoreFileInfo.java:360)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile.getModificationTimeStamp(StoreFile.java:321)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreUtils.getLowestTimestamp(StoreUtils.java:63)
> at
> org.apache.hadoop.hbase.regionserver.compactions.RatioBasedCompactionPolicy.shouldPerformMajorCompaction(RatioBasedCompactionPolicy.java:63)
> at
> org.apache.hadoop.hbase.regionserver.compactions.SortedCompactionPolicy.selectCompaction(SortedCompactionPolicy.java:82)
>
> at
> org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.select(DefaultStoreEngine.java:107)
>
> at
> org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(HStore.java:1644)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread.selectCompaction(CompactSplitThread.java:373)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread.access$100(CompactSplitThread.java:59)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.doCompaction(CompactSplitThread.java:498)
> at
> org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.run(CompactSplitThread.java:568)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 16/09/27 17:01:31 ERROR regionserver.CompactSplitThread: Compaction selection
> failed Store = XXX, pri = 115
> java.io.FileNotFoundException: File does not exist:
> hdfs://.../hbase/data/ns/table/region/cf/XXfilenameXX
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1309)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$22.doCall(DistributedFileSystem.java:1301)
> at
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1317)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:421)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getReferencedFileStatus(StoreFileInfo.java:342)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getFileStatus(StoreFileInfo.java:355)
>
> at
> org.apache.hadoop.hbase.regionserver.StoreFileInfo.getModificationTime(StoreFileInfo.java:360)
> at
>
[jira] [Updated] (HBASE-11392) Replication requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-11392: -- Priority: Critical (was: Major) > Replication requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Talat UYARER >Priority: Critical > Fix For: 2.0.0 > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11392) Replication requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583012#comment-15583012 ] Enis Soztutar commented on HBASE-11392: --- [~talat] you had a almost-finished patch for this, no? Do you mind attaching it so that we can finish it by 2.0 timeframe. It's fine if it is not even compiling. > Replication requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Talat UYARER > Fix For: 2.0.0 > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16861) xxxService refactoring
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582998#comment-15582998 ] Ted Yu commented on HBASE-16861: The description says Operation but the patch has XXTask.java Update the subject and description so that they're consistent. > xxxService refactoring > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16861-v1.patch > > > Rename BackupCopyService and RestoreServive to xxxOperation. They are not > services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16861) xxxService refactoring
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16861: -- Attachment: HBASE-16861-v1.patch v1. Tests pass. > xxxService refactoring > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16861-v1.patch > > > Rename BackupCopyService and RestoreServive to xxxOperation. They are not > services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16861) xxxService refactoring
[ https://issues.apache.org/jira/browse/HBASE-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582988#comment-15582988 ] Vladimir Rodionov edited comment on HBASE-16861 at 10/17/16 6:18 PM: - v1. Tests pass. cc: [~tedyu] was (Author: vrodionov): v1. Tests pass. > xxxService refactoring > -- > > Key: HBASE-16861 > URL: https://issues.apache.org/jira/browse/HBASE-16861 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16861-v1.patch > > > Rename BackupCopyService and RestoreServive to xxxOperation. They are not > services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16860) BackupCopyService#Type refactoring
[ https://issues.apache.org/jira/browse/HBASE-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16860: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Thanks, Vlad. > BackupCopyService#Type refactoring > -- > > Key: HBASE-16860 > URL: https://issues.apache.org/jira/browse/HBASE-16860 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-16860-v1.patch > > > We have duplicate enums: > BackupType and BackupCopyService.Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16860) BackupCopyService#Type refactoring
[ https://issues.apache.org/jira/browse/HBASE-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-16860: --- Summary: BackupCopyService#Type refactoring (was: BackupCopyService Type refactoring) > BackupCopyService#Type refactoring > -- > > Key: HBASE-16860 > URL: https://issues.apache.org/jira/browse/HBASE-16860 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16860-v1.patch > > > We have duplicate enums: > BackupType and BackupCopyService.Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16860) BackupCopyService Type refactoring
[ https://issues.apache.org/jira/browse/HBASE-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16860: -- Description: We have duplicate enums: BackupType and BackupCopyService.Type was: We have duplicate enums: BackupType and BackupCopuService.Type > BackupCopyService Type refactoring > -- > > Key: HBASE-16860 > URL: https://issues.apache.org/jira/browse/HBASE-16860 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16860-v1.patch > > > We have duplicate enums: > BackupType and BackupCopyService.Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16860) BackupCopyService Type refactoring
[ https://issues.apache.org/jira/browse/HBASE-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582929#comment-15582929 ] Vladimir Rodionov edited comment on HBASE-16860 at 10/17/16 6:00 PM: - [~appy] has pointed that out. Test pass. Please commit it, it blocks some other refactoring stuff. was (Author: vrodionov): [~appy] has pointed that out. > BackupCopyService Type refactoring > -- > > Key: HBASE-16860 > URL: https://issues.apache.org/jira/browse/HBASE-16860 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16860-v1.patch > > > We have duplicate enums: > BackupType and BackupCopuService.Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16862) Remove directory layout/ filesystem references form the code in master/procedure directory
Umesh Agashe created HBASE-16862: Summary: Remove directory layout/ filesystem references form the code in master/procedure directory Key: HBASE-16862 URL: https://issues.apache.org/jira/browse/HBASE-16862 Project: HBase Issue Type: Sub-task Components: Filesystem Integration Reporter: Umesh Agashe Assignee: Umesh Agashe Remove directory layout/ filesystem references form the code in master/procedure directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16860) BackupCopyService Type refactoring
[ https://issues.apache.org/jira/browse/HBASE-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582929#comment-15582929 ] Vladimir Rodionov edited comment on HBASE-16860 at 10/17/16 5:59 PM: - [~appy] has pointed that out. was (Author: vrodionov): [~apeksharma] has pointed that out. > BackupCopyService Type refactoring > -- > > Key: HBASE-16860 > URL: https://issues.apache.org/jira/browse/HBASE-16860 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16860-v1.patch > > > We have duplicate enums: > BackupType and BackupCopuService.Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16860) BackupCopyService Type refactoring
[ https://issues.apache.org/jira/browse/HBASE-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16860: -- Description: We have duplicate enums: BackupType and BackupCopuService.Type > BackupCopyService Type refactoring > -- > > Key: HBASE-16860 > URL: https://issues.apache.org/jira/browse/HBASE-16860 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16860-v1.patch > > > We have duplicate enums: > BackupType and BackupCopuService.Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16860) BackupCopyService Type refactoring
[ https://issues.apache.org/jira/browse/HBASE-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582929#comment-15582929 ] Vladimir Rodionov commented on HBASE-16860: --- [~apeksharma] has pointed that out. > BackupCopyService Type refactoring > -- > > Key: HBASE-16860 > URL: https://issues.apache.org/jira/browse/HBASE-16860 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-16860-v1.patch > > > We have duplicate enums: > BackupType and BackupCopuService.Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16789) Remove directory layout/ filesystem references from CompactionTool
[ https://issues.apache.org/jira/browse/HBASE-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582923#comment-15582923 ] Umesh Agashe commented on HBASE-16789: -- [~busbey], here are a few points that are discussed: * This is an offline Compaction Tool (CT). Without MR option, CT will compact files for input table/ region/ column family on local node where CT is run. * Current CT, decides on node to run MR jobs based on location of first block of a first file in an input directory. * This can be improved to consider nodes based on last know region assignments with fallback on location of first block of first file in a table/ region/ column family. This will provide better locality. * Even with the improved logic, locality cannot be guaranteed. * So, whether to run with MR and MR job node selection can be determined by code outside of CT or a User. CT will be just responsible for compaction of files for input table/ region/ cf without deciding on MR or node selection for MR. * CT may query/ consider local regions and only compact files belonging to local regions. Workaround with -force option can be provided for the default behavior. > Remove directory layout/ filesystem references from CompactionTool > -- > > Key: HBASE-16789 > URL: https://issues.apache.org/jira/browse/HBASE-16789 > Project: HBase > Issue Type: Sub-task > Components: Filesystem Integration >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Attachments: HBASE-16789-hbase-14439.v1.patch > > > Remove directory layout/ filesystem references from CompactionTool and use > APIs provided by MasterStorage/ RegionStorage instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16846) Procedure v2 - executor cleanup
[ https://issues.apache.org/jira/browse/HBASE-16846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-16846: Resolution: Fixed Status: Resolved (was: Patch Available) > Procedure v2 - executor cleanup > --- > > Key: HBASE-16846 > URL: https://issues.apache.org/jira/browse/HBASE-16846 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16846-v0.patch > > > Trying to reorganize the executor. move some code around grouping common > code, remove some synchronization from Procedure and adding comments on > various sections. > the execution logic remains unchanged -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16783) Use ByteBufferPool for the header and message during Rpc response
[
https://issues.apache.org/jira/browse/HBASE-16783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582869#comment-15582869
]
Anoop Sam John commented on HBASE-16783:
{code}
this.poolManager.checkSizeAndGrow(extra);
59 // update the curBuf reference in case a new buffer was allocated
60 this.curBuf = this.poolManager.getCurrentBuffer();
61}
{code}
BBLOS method is having this.. I think it is not a clean approach.. The
checkSize and managing all writes should be within the BBLOS only.. What we
really need is a structure which can separate out bufs from pool and on demand
created one.. This class should be able to give buffers when some one ask for
one. If available, from pool or else on heap created one. Also to have a
close() method or so which can release the bufs to pool (which we got from
pool).. But this new class should not be responsible check size and do any
sort of writes or so.
> Use ByteBufferPool for the header and message during Rpc response
> -
>
> Key: HBASE-16783
> URL: https://issues.apache.org/jira/browse/HBASE-16783
> Project: HBase
> Issue Type: Improvement
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Minor
> Attachments: HBASE-16783.patch, HBASE-16783_1.patch,
> HBASE-16783_2.patch, HBASE-16783_3.patch
>
>
> With ByteBufferPool in place we could avoid the byte[] creation in
> RpcServer#createHeaderAndMessageBytes and try using the Buffer from the pool
> rather than creating byte[] every time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
