[jira] [Comment Edited] (HBASE-16814) FuzzyRowFilter causes remote call timeout
[ https://issues.apache.org/jira/browse/HBASE-16814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002100#comment-16002100 ] Hadi Kahraman edited comment on HBASE-16814 at 5/9/17 5:58 AM: --- Sorry for the late response. I don't know what "unsafe" is, there isn't "unsafe" in my hbase-site.xml, I couldn't find anything about such a configurable in hbase-1.1.4/docs/book.html. What should I check? was (Author: hadi.kahraman): Sorry for the late response. I don't what "unsafe" is, there isn't "unsafe" in my hbase-site.xml, I couldn't find anything about such a configurable in hbase-1.1.4/docs/book.html. What should I check? > FuzzyRowFilter causes remote call timeout > - > > Key: HBASE-16814 > URL: https://issues.apache.org/jira/browse/HBASE-16814 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.2.2, 1.2.3 > Environment: LinuxMint 17.3 (=Ubuntu 14.04), Java 1.8 >Reporter: Hadi Kahraman > > FuzzyRowFilter causes ResultScanner.next hang and timeout. The same code > works well on hbase 1.2.1, 1.2.0, 1.1.4. > hbase server: cloudera 5.7.0 (hbase 1.2.0) on 4 hosts, 1 master, 3 workers -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16814) FuzzyRowFilter causes remote call timeout
[ https://issues.apache.org/jira/browse/HBASE-16814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002100#comment-16002100 ] Hadi Kahraman commented on HBASE-16814: --- Sorry for the late response. I don't what "unsafe" is, there isn't "unsafe" in my hbase-site.xml, I couldn't find anything about such a configurable in hbase-1.1.4/docs/book.html. What should I check? > FuzzyRowFilter causes remote call timeout > - > > Key: HBASE-16814 > URL: https://issues.apache.org/jira/browse/HBASE-16814 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.2.2, 1.2.3 > Environment: LinuxMint 17.3 (=Ubuntu 14.04), Java 1.8 >Reporter: Hadi Kahraman > > FuzzyRowFilter causes ResultScanner.next hang and timeout. The same code > works well on hbase 1.2.1, 1.2.0, 1.1.4. > hbase server: cloudera 5.7.0 (hbase 1.2.0) on 4 hosts, 1 master, 3 workers -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18017) Reduce frequency of setStoragePolicy failure warnings
[
https://issues.apache.org/jira/browse/HBASE-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002089#comment-16002089
]
Yu Li commented on HBASE-18017:
---
overall LGTM, +1.
One minor question, that I noticed log level of {{Set storagePolicy=xxx for
path=xxx}} has been reduced from INFO to TRACE, but why not DEBUG? Is it too
frequent in your observation? This message might be useful to confirm storage
policy when debugging (although we could also get policy type through hdfs
command, but for some already deleted hfile/wal we might have no chance).
Thanks.
> Reduce frequency of setStoragePolicy failure warnings
> -
>
> Key: HBASE-18017
> URL: https://issues.apache.org/jira/browse/HBASE-18017
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Attachments: HBASE-18017.patch
>
>
> When running with storage policy specification support if the underlying HDFS
> doesn't support it or if it has been disabled in site configuration the
> resulting logging is excessive. Log at WARN level once per FileSystem
> instance. Otherwise, log messages at DEBUG level.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17738) BucketCache startup is slow
[ https://issues.apache.org/jira/browse/HBASE-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002051#comment-16002051 ] ramkrishna.s.vasudevan commented on HBASE-17738: Yes I think Stack has referred to this link some where earlier also. They are using some jemalloc script to avoid fragmentation. But yes we can have a look at their impl to see how these allocations happen. > BucketCache startup is slow > --- > > Key: HBASE-17738 > URL: https://issues.apache.org/jira/browse/HBASE-17738 > Project: HBase > Issue Type: Sub-task > Components: BucketCache >Affects Versions: 2.0.0 >Reporter: stack >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-17738.patch > > > If you set bucketcache size at 64G say and then start hbase, it takes a long > time. Can we do the allocations in parallel and not inline with the server > startup? > Related, prefetching on a bucketcache is slow. Speed it up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14925) Develop HBase shell command/tool to list table's region info through command line
[ https://issues.apache.org/jira/browse/HBASE-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002047#comment-16002047 ] Hudson commented on HBASE-14925: FAILURE: Integrated in Jenkins build HBase-1.4 #727 (See [https://builds.apache.org/job/HBase-1.4/727/]) HBASE-14925 Addendum patch for 'list_regions' that support column (apurtell: rev 8d51c83712d0cf799c364cecca7e33af7d0b1397) * (edit) hbase-shell/src/main/ruby/shell/commands/list_regions.rb > Develop HBase shell command/tool to list table's region info through command > line > - > > Key: HBASE-14925 > URL: https://issues.apache.org/jira/browse/HBASE-14925 > Project: HBase > Issue Type: Improvement > Components: shell >Reporter: Romil Choksi >Assignee: Karan Mehta > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-14925.002.patch, > HBASE-14925.003.addendum.001.patch, HBASE-14925.003.patch, HBASE-14925.patch > > > I am going through the hbase shell commands to see if there is anything I can > use to get all the regions info just for a particular table. I don’t see any > such command that provides me that information. > It would be better to have a command that provides region info, start key, > end key etc taking a table name as the input parameter. This is available > through HBase UI on clicking on a particular table's link > A tool/shell command to get a list of regions for a table or all tables in a > tabular structured output (that is machine readable) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17973) Create shell command to identify regions with poor locality
[
https://issues.apache.org/jira/browse/HBASE-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002046#comment-16002046
]
Hudson commented on HBASE-17973:
FAILURE: Integrated in Jenkins build HBase-1.4 #727 (See
[https://builds.apache.org/job/HBase-1.4/727/])
HBASE-17973 Create shell command to identify regions with poor locality
(apurtell: rev eaaf70354f6d4e4ecfb18c1ff33389c19da5a2b3)
* (add) hbase-shell/src/test/ruby/hbase/list_regions_test_no_cluster.rb
* (edit) hbase-shell/src/main/ruby/shell/commands/list_regions.rb
* (edit) hbase-shell/src/main/ruby/hbase.rb
HBASE-17973 Fix incorrect method call in list_regions and expand tests
(apurtell: rev 1d33f619188bfabe51c7ed217102e897e3c105e9)
* (edit) hbase-shell/src/test/ruby/hbase/list_regions_test_no_cluster.rb
* (edit) hbase-shell/src/main/ruby/shell/commands/list_regions.rb
> Create shell command to identify regions with poor locality
> ---
>
> Key: HBASE-17973
> URL: https://issues.apache.org/jira/browse/HBASE-17973
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17973.001.patch, HBASE-17973.002.patch,
> HBASE-17973.003.patch, HBASE-17973.branch-1.001.patch
>
>
> The data locality of regions often plays a large role in the efficiency of
> HBase. Compactions are also expensive to execute, especially on very large
> tables. The balancer can do a good job trying to maintain locality (when
> tuned properly), but it is not perfect.
> This creates a less-than-desirable situation where it's a costly operation to
> take a cluster with spotty poor locality (e.g. a small percentage of
> regionservers with poor locality).
> We already have this information available via the {{ClusterStatus}} proto.
> We can easily write a shell command that can present regions which are
> lacking a certain percentage of locality.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18014) A case of Region remain unassigned when table enabled
[
https://issues.apache.org/jira/browse/HBASE-18014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002042#comment-16002042
]
Allan Yang commented on HBASE-18014:
Failed UT are passed locally, issues in Findbugs are not introduced by my code.
> A case of Region remain unassigned when table enabled
> -
>
> Key: HBASE-18014
> URL: https://issues.apache.org/jira/browse/HBASE-18014
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.4.0, 1.1.10
>Reporter: Allan Yang
>Assignee: Allan Yang
> Attachments: HBASE-18014-branch-1.patch, HBASE-18014-branch-1.v2.patch
>
>
> Reproduce procedure:
> 1. Create a table, say the regions of this table are opened on RS1
> 2. Disable this table
> 3. Abort RS1 and wait for SSH to complete
> 4. Wait for a while, RS1 will be deleted from processedServers(a HashMap in
> {{RegionState}} to store processed dead servers)
> 5. Enable the table, then the region of the table will remain unassigned
> until master restarts.
> Why?
> When assigning regions after the table enabled, AssignmentManager will check
> whether those regions are on servers which are dead but not processed, since
> RS1 already have deleted from the map of 'processedServers'. Then the
> AssignmentManager think this region is on a dead but not processed server. So
> it will skip assign, let the region be handled by SSH.
> {code:java}
> case OFFLINE:
> if (useZKForAssignment
> && regionStates.isServerDeadAndNotProcessed(sn)
> && wasRegionOnDeadServerByMeta(region, sn)) {
> if (!regionStates.isRegionInTransition(region)) {
> LOG.info("Updating the state to " + State.OFFLINE + " to allow to
> be reassigned by SSH");
> regionStates.updateRegionState(region, State.OFFLINE);
> }
> LOG.info("Skip assigning " + region.getRegionNameAsString()
> + ", it is on a dead but not processed yet server: " + sn);
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18009) Move RpcServer.Call to a separated file
[ https://issues.apache.org/jira/browse/HBASE-18009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002030#comment-16002030 ] Yu Li commented on HBASE-18009: --- +1 on patch v1 (and release note). > Move RpcServer.Call to a separated file > --- > > Key: HBASE-18009 > URL: https://issues.apache.org/jira/browse/HBASE-18009 > Project: HBase > Issue Type: Sub-task > Components: IPC/RPC >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-18009.patch, HBASE-18009-v1.patch > > > For making RpcServer easier to read. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17924) Consider sorting the row order when processing multi() ops before taking rowlocks
[
https://issues.apache.org/jira/browse/HBASE-17924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002019#comment-16002019
]
Hudson commented on HBASE-17924:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2976 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2976/])
HBASE-17924 Consider sorting the row order when processing multi() ops
(apurtell: rev 959deb0e5c7c43c2cda6fe4b5c4d46ed80d3d8e6)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
* (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java
> Consider sorting the row order when processing multi() ops before taking
> rowlocks
> -
>
> Key: HBASE-17924
> URL: https://issues.apache.org/jira/browse/HBASE-17924
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0, 1.1.8
>Reporter: Andrew Purtell
>Assignee: Allan Yang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17924.patch, HBASE-17924.v0.patch,
> HBASE-17924.v2.patch, HBASE-17924.v3.patch, HBASE-17924.v4.patch,
> HBASE-17924.v5.patch
>
>
> When processing a batch mutation, we take row locks in whatever order the
> mutations were added to the multi op by the client.
>
> {noformat}
> RSRpcServices#multi -> RSRpcServices#mutateRows -> HRegion#mutateRow ->
> HRegion#mutateRowsWithLocks -> HRegion#processRowsWithLocks
> {noformat}
> Or
> {noformat}
> RSRpcServices#multi -> RSRpcServices#doNonAtomicRegionMutation ->
> HRegion#get
> | HRegion#append
> | HRegion#increment
> | HRegionServer#doBatchOp -> HRegion#batchMutate ->
> HRegion#doMiniBatchMutation
> {noformat}
>
> multi() is fed by client APIs that accept a RowMutations object containing
> actions for multiple rows. The container for ops inside RowMutations is an
> ArrayList, which doesn't change the ordering of objects added to it. The
> protobuf implementation of the messages for multi ops do not reorder the list
> of actions. When processing multi ops we iterate over the actions in the
> order rehydrated from protobuf.
> We should discuss sorting the order of ops by row key when processing multi()
> ops before taking row locks. Does this make lock ordering more predictable
> for server side operations? Yes, but potentially surprising for the client,
> right? Is there any legitimate reason we should take locks out of row key
> sorted order because the client has structured the request as such?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18014) A case of Region remain unassigned when table enabled
[
https://issues.apache.org/jira/browse/HBASE-18014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002014#comment-16002014
]
Hadoop QA commented on HBASE-18014:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
52s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} branch-1 passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
56s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 58s
{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 25s
{color} | {color:green} branch-1 passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
56s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 10s {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
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s
{color} | {color:green} the patch passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 87m 37s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 117m 39s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestReplicasClient |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:58c504e |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12867024/HBASE-18014-branch-1.v2.patch
|
| JIRA Issue | HBASE-18014 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux e033d4bf848e 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/hbase.sh |
| git revision | branch-1 / 8d51c83
[jira] [Commented] (HBASE-18016) Implement abort for TruncateTableProcedure
[
https://issues.apache.org/jira/browse/HBASE-18016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002005#comment-16002005
]
stack commented on HBASE-18016:
---
Agree that if you look at TruncateTableProcedure, it doesn't seem to make sense
adding an abort but fact is that Procedures will have corner cases.
In this case, what we saw was an infinite loop of the following:
{code}
2017-04-18 21:06:05,392 WARN
org.apache.hadoop.hbase.master.procedure.TruncateTableProcedure: Retriable
error trying to truncate table=state=TRUNCATE_TABLE_CREATE_FS_LAYOUT
java.io.IOException: java.util.concurrent.ExecutionException:
java.io.IOException: The specified region already exists on disk:
hdfs://nameservice1/hbase/XX/.tmp/data/default/YY/b76c62fb69c0aa8e667adfd604a22c69
2017-04-18 21:06:05,176 WARN
org.apache.hadoop.hbase.regionserver.HRegionFileSystem: Trying to create a
region that already exists on disk:
hdfs://nameservice1/hbase/xx/.tmp/data/default/YYY/b76c62fb69c0aa8e667adfd604a22c69
{code}
Truncate had borked itself. The above condition is probably fixable... i.e.
Truncate should recognize this state where it has mangled events and deal
appropriately ... but ti will take a while till we have ironed out all corner
cases.
Meantime, operators should be able to kill/abort Procedures gone wild whatever
the reason.
> Implement abort for TruncateTableProcedure
> --
>
> Key: HBASE-18016
> URL: https://issues.apache.org/jira/browse/HBASE-18016
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0
>
>
> TruncateTableProcedure can not be aborted as abort is not implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999251#comment-15999251 ] Xiang Li edited comment on HBASE-15199 at 5/9/17 4:18 AM: -- Hi [~busbey] I uploaded a new patch based on the current master branch. I never worked for a patch as "addendum" before, but if it means a patch to contain the diff based on the current status, and does not contain the already committed changes for HBASE-15199, then it is as uploaded. Would you please review? The logic is updated as : (1) for the commands which need jruby (currently shell and org.jruby.Main) A. when JRUBY_HOME is specified explicitly, eg. export JRUBY_HOME=/usr/local/share/jruby CLASSPATH and HBASE_OPTS are updated according to JRUBY_HOME specified B. when JRUBY_HOME is not specified explicitly add jruby packaged with HBase to CLASSPATH (2) for other commands, do nothing was (Author: water): Hi [~busbey] I uploaded a new patch based on the current master branch. I never worked for a patch as "addendum" before, but it means a patch to contain the diff based on the current status, and does not contain the already committed changes for HBASE-15199, then it is as uploaded. Would you please review? The logic is updated as : (1) for the commands which need jruby (currently shell and org.jruby.Main) A. when JRUBY_HOME is specified explicitly, eg. export JRUBY_HOME=/usr/local/share/jruby CLASSPATH and HBASE_OPTS are updated according to JRUBY_HOME specified B. when JRUBY_HOME is not specified explicitly add jruby packaged with HBase to CLASSPATH (2) for other commands, do nothing > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199-addendum.master.000.patch, > HBASE-15199.master.001.patch, HBASE-15199.master.002.patch, > HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001935#comment-16001935 ] Xiang Li edited comment on HBASE-15199 at 5/9/17 4:17 AM: -- [~busbey] Would you please let me know if I need to do something else for this JIRA? was (Author: water): [~busbey] Would you please let me know if I need to something else for this JIRA? > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199-addendum.master.000.patch, > HBASE-15199.master.001.patch, HBASE-15199.master.002.patch, > HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-8758) Error in RegionCoprocessorHost class preScanner method documentation.
[ https://issues.apache.org/jira/browse/HBASE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001983#comment-16001983 ] Chia-Ping Tsai commented on HBASE-8758: --- +1 > Error in RegionCoprocessorHost class preScanner method documentation. > - > > Key: HBASE-8758 > URL: https://issues.apache.org/jira/browse/HBASE-8758 > Project: HBase > Issue Type: Bug > Components: Coprocessors, documentation >Affects Versions: 0.98.0, 0.95.2, 0.94.9 > Environment: Any. Actually it is just wrong comment in code. >Reporter: Roman Nikitchenko >Priority: Minor > Labels: beginner, comments, coprocessors, documentation > Attachments: 8758-r1545168.patch, HBASE-8758-r1545168.patch, > HBASE-8758-r1545168.patch > > > preScannerOpen() method of RegionCoprocessorHost class is documented to > return 'false' value in negative case (default operation should not be > bypassed). Actual implementation returns 'null' value. > Proposed solution is just to correct comment to match existing implementation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17210) Set timeout on trying rowlock according to client's RPC timeout
[ https://issues.apache.org/jira/browse/HBASE-17210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001981#comment-16001981 ] stack commented on HBASE-17210: --- Thanks [~yangzhe1991] Yeah, it looks like lock is not released correctly. Looking for clues and arrived here thanks. > Set timeout on trying rowlock according to client's RPC timeout > --- > > Key: HBASE-17210 > URL: https://issues.apache.org/jira/browse/HBASE-17210 > Project: HBase > Issue Type: Sub-task >Reporter: Phil Yang >Assignee: Phil Yang > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-17120.v1.patch, HBASE-17210.branch-1.v01.patch, > HBASE-17210.branch-1.v02.patch, HBASE-17210.branch-1.v03.patch, > HBASE-17210.v02.patch, HBASE-17210.v03.patch, HBASE-17210.v04.patch, > HBASE-17210.v04.patch > > > Now when we want to get a row lock, the timeout is fixed and default is 30s. > But the requests from client have different RPC timeout setting. We can use > the client's deadline to set timeout on tryLock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17210) Set timeout on trying rowlock according to client's RPC timeout
[ https://issues.apache.org/jira/browse/HBASE-17210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001979#comment-16001979 ] Phil Yang commented on HBASE-17210: --- Before this patch, if a Call with 1000ms timeout being blocked by getting a row lock, the request will be regarded as timeout at client but the handler will not be released until it gets the lock and do the work. In the worst case the handler will be occupied for 30s because the default timeout for getting row lock is 30s. After this patch, if a Call's timeout is 1000ms, the timeout of tryLock will also be 1000ms. If timeout, we will throw a TimeoutIOException and the handler will be released. bq. Asking because seeing something where all handlers are blocked trying to get a lock but weirdly no handler seems to have the lock; i.e. no one is doing work. The lock is not released correctly? In this patch we only throw exception when tryLock return false which means the lock is not acquired. > Set timeout on trying rowlock according to client's RPC timeout > --- > > Key: HBASE-17210 > URL: https://issues.apache.org/jira/browse/HBASE-17210 > Project: HBase > Issue Type: Sub-task >Reporter: Phil Yang >Assignee: Phil Yang > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-17120.v1.patch, HBASE-17210.branch-1.v01.patch, > HBASE-17210.branch-1.v02.patch, HBASE-17210.branch-1.v03.patch, > HBASE-17210.v02.patch, HBASE-17210.v03.patch, HBASE-17210.v04.patch, > HBASE-17210.v04.patch > > > Now when we want to get a row lock, the timeout is fixed and default is 30s. > But the requests from client have different RPC timeout setting. We can use > the client's deadline to set timeout on tryLock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001957#comment-16001957 ] Jerry He commented on HBASE-15199: -- +1 on the addendum. > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199-addendum.master.000.patch, > HBASE-15199.master.001.patch, HBASE-15199.master.002.patch, > HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17924) Consider sorting the row order when processing multi() ops before taking rowlocks
[
https://issues.apache.org/jira/browse/HBASE-17924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001954#comment-16001954
]
Hudson commented on HBASE-17924:
FAILURE: Integrated in Jenkins build HBase-1.4 #726 (See
[https://builds.apache.org/job/HBase-1.4/726/])
HBASE-17924 Consider sorting the row order when processing multi() ops
(apurtell: rev 0f6a2c41133b2d800389be81f3aefe4589ec1625)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
* (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java
> Consider sorting the row order when processing multi() ops before taking
> rowlocks
> -
>
> Key: HBASE-17924
> URL: https://issues.apache.org/jira/browse/HBASE-17924
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0, 1.1.8
>Reporter: Andrew Purtell
>Assignee: Allan Yang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17924.patch, HBASE-17924.v0.patch,
> HBASE-17924.v2.patch, HBASE-17924.v3.patch, HBASE-17924.v4.patch,
> HBASE-17924.v5.patch
>
>
> When processing a batch mutation, we take row locks in whatever order the
> mutations were added to the multi op by the client.
>
> {noformat}
> RSRpcServices#multi -> RSRpcServices#mutateRows -> HRegion#mutateRow ->
> HRegion#mutateRowsWithLocks -> HRegion#processRowsWithLocks
> {noformat}
> Or
> {noformat}
> RSRpcServices#multi -> RSRpcServices#doNonAtomicRegionMutation ->
> HRegion#get
> | HRegion#append
> | HRegion#increment
> | HRegionServer#doBatchOp -> HRegion#batchMutate ->
> HRegion#doMiniBatchMutation
> {noformat}
>
> multi() is fed by client APIs that accept a RowMutations object containing
> actions for multiple rows. The container for ops inside RowMutations is an
> ArrayList, which doesn't change the ordering of objects added to it. The
> protobuf implementation of the messages for multi ops do not reorder the list
> of actions. When processing multi ops we iterate over the actions in the
> order rehydrated from protobuf.
> We should discuss sorting the order of ops by row key when processing multi()
> ops before taking row locks. Does this make lock ordering more predictable
> for server side operations? Yes, but potentially surprising for the client,
> right? Is there any legitimate reason we should take locks out of row key
> sorted order because the client has structured the request as such?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18014) A case of Region remain unassigned when table enabled
[
https://issues.apache.org/jira/browse/HBASE-18014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001953#comment-16001953
]
Allan Yang commented on HBASE-18014:
{quote}
Related to HBASE-17055 ?
{quote}
Looks like it is. Ping [~syuanjiang].
> A case of Region remain unassigned when table enabled
> -
>
> Key: HBASE-18014
> URL: https://issues.apache.org/jira/browse/HBASE-18014
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.4.0, 1.1.10
>Reporter: Allan Yang
>Assignee: Allan Yang
> Attachments: HBASE-18014-branch-1.patch, HBASE-18014-branch-1.v2.patch
>
>
> Reproduce procedure:
> 1. Create a table, say the regions of this table are opened on RS1
> 2. Disable this table
> 3. Abort RS1 and wait for SSH to complete
> 4. Wait for a while, RS1 will be deleted from processedServers(a HashMap in
> {{RegionState}} to store processed dead servers)
> 5. Enable the table, then the region of the table will remain unassigned
> until master restarts.
> Why?
> When assigning regions after the table enabled, AssignmentManager will check
> whether those regions are on servers which are dead but not processed, since
> RS1 already have deleted from the map of 'processedServers'. Then the
> AssignmentManager think this region is on a dead but not processed server. So
> it will skip assign, let the region be handled by SSH.
> {code:java}
> case OFFLINE:
> if (useZKForAssignment
> && regionStates.isServerDeadAndNotProcessed(sn)
> && wasRegionOnDeadServerByMeta(region, sn)) {
> if (!regionStates.isRegionInTransition(region)) {
> LOG.info("Updating the state to " + State.OFFLINE + " to allow to
> be reassigned by SSH");
> regionStates.updateRegionState(region, State.OFFLINE);
> }
> LOG.info("Skip assigning " + region.getRegionNameAsString()
> + ", it is on a dead but not processed yet server: " + sn);
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18014) A case of Region remain unassigned when table enabled
[
https://issues.apache.org/jira/browse/HBASE-18014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001947#comment-16001947
]
Guangxu Cheng commented on HBASE-18014:
---
Related to HBASE-17055 ?
> A case of Region remain unassigned when table enabled
> -
>
> Key: HBASE-18014
> URL: https://issues.apache.org/jira/browse/HBASE-18014
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.4.0, 1.1.10
>Reporter: Allan Yang
>Assignee: Allan Yang
> Attachments: HBASE-18014-branch-1.patch, HBASE-18014-branch-1.v2.patch
>
>
> Reproduce procedure:
> 1. Create a table, say the regions of this table are opened on RS1
> 2. Disable this table
> 3. Abort RS1 and wait for SSH to complete
> 4. Wait for a while, RS1 will be deleted from processedServers(a HashMap in
> {{RegionState}} to store processed dead servers)
> 5. Enable the table, then the region of the table will remain unassigned
> until master restarts.
> Why?
> When assigning regions after the table enabled, AssignmentManager will check
> whether those regions are on servers which are dead but not processed, since
> RS1 already have deleted from the map of 'processedServers'. Then the
> AssignmentManager think this region is on a dead but not processed server. So
> it will skip assign, let the region be handled by SSH.
> {code:java}
> case OFFLINE:
> if (useZKForAssignment
> && regionStates.isServerDeadAndNotProcessed(sn)
> && wasRegionOnDeadServerByMeta(region, sn)) {
> if (!regionStates.isRegionInTransition(region)) {
> LOG.info("Updating the state to " + State.OFFLINE + " to allow to
> be reassigned by SSH");
> regionStates.updateRegionState(region, State.OFFLINE);
> }
> LOG.info("Skip assigning " + region.getRegionNameAsString()
> + ", it is on a dead but not processed yet server: " + sn);
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17887: --- Status: Patch Available (was: Open) > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, > HBASE-17887.v2.patch, HBASE-17887.v3.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17887: --- Attachment: HBASE-17887.v3.patch v3.patch -- # The failed tests passed on my local machine. # fix the findbugs warns > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, > HBASE-17887.v2.patch, HBASE-17887.v3.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17887: --- Status: Open (was: Patch Available) > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, > HBASE-17887.v2.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-18014) A case of Region remain unassigned when table enabled
[
https://issues.apache.org/jira/browse/HBASE-18014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allan Yang updated HBASE-18014:
---
Attachment: HBASE-18014-branch-1.v2.patch
> A case of Region remain unassigned when table enabled
> -
>
> Key: HBASE-18014
> URL: https://issues.apache.org/jira/browse/HBASE-18014
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.4.0, 1.1.10
>Reporter: Allan Yang
>Assignee: Allan Yang
> Attachments: HBASE-18014-branch-1.patch, HBASE-18014-branch-1.v2.patch
>
>
> Reproduce procedure:
> 1. Create a table, say the regions of this table are opened on RS1
> 2. Disable this table
> 3. Abort RS1 and wait for SSH to complete
> 4. Wait for a while, RS1 will be deleted from processedServers(a HashMap in
> {{RegionState}} to store processed dead servers)
> 5. Enable the table, then the region of the table will remain unassigned
> until master restarts.
> Why?
> When assigning regions after the table enabled, AssignmentManager will check
> whether those regions are on servers which are dead but not processed, since
> RS1 already have deleted from the map of 'processedServers'. Then the
> AssignmentManager think this region is on a dead but not processed server. So
> it will skip assign, let the region be handled by SSH.
> {code:java}
> case OFFLINE:
> if (useZKForAssignment
> && regionStates.isServerDeadAndNotProcessed(sn)
> && wasRegionOnDeadServerByMeta(region, sn)) {
> if (!regionStates.isRegionInTransition(region)) {
> LOG.info("Updating the state to " + State.OFFLINE + " to allow to
> be reassigned by SSH");
> regionStates.updateRegionState(region, State.OFFLINE);
> }
> LOG.info("Skip assigning " + region.getRegionNameAsString()
> + ", it is on a dead but not processed yet server: " + sn);
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001935#comment-16001935 ] Xiang Li commented on HBASE-15199: -- [~busbey] Would you please let me know if I need to something else for this JIRA? > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199-addendum.master.000.patch, > HBASE-15199.master.001.patch, HBASE-15199.master.002.patch, > HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18017) Reduce frequency of setStoragePolicy failure warnings
[
https://issues.apache.org/jira/browse/HBASE-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001906#comment-16001906
]
Hadoop QA commented on HBASE-18017:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 27s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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} 6m
11s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 20s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s {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} 4m
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 18s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 18s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
55m 8s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 111m 48s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
1s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 193m 4s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestMobSecureExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestMobExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestExportSnapshot |
| | org.apache.hadoop.hbase.TestPartialResultsFromClientSide |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866989/HBASE-18017.patch |
| JIRA Issue | HBASE-18017 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux b711e9422f17 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 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 / 3dc38a4 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6733/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/6733/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6733/testReport/ |
|
[jira] [Updated] (HBASE-14925) Develop HBase shell command/tool to list table's region info through command line
[ https://issues.apache.org/jira/browse/HBASE-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14925: --- Resolution: Fixed Status: Resolved (was: Patch Available) Committed the addendum to branch-1 after applying [~karanmehta93]'s backport of HBASE-17973. Thanks for the help with the backport! > Develop HBase shell command/tool to list table's region info through command > line > - > > Key: HBASE-14925 > URL: https://issues.apache.org/jira/browse/HBASE-14925 > Project: HBase > Issue Type: Improvement > Components: shell >Reporter: Romil Choksi >Assignee: Karan Mehta > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-14925.002.patch, > HBASE-14925.003.addendum.001.patch, HBASE-14925.003.patch, HBASE-14925.patch > > > I am going through the hbase shell commands to see if there is anything I can > use to get all the regions info just for a particular table. I don’t see any > such command that provides me that information. > It would be better to have a command that provides region info, start key, > end key etc taking a table name as the input parameter. This is available > through HBase UI on clicking on a particular table's link > A tool/shell command to get a list of regions for a table or all tables in a > tabular structured output (that is machine readable) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17973) Create shell command to identify regions with poor locality
[
https://issues.apache.org/jira/browse/HBASE-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-17973:
---
Fix Version/s: 1.4.0
Pushed to branch-1. Thanks for help with the backport [~karanmehta93]
> Create shell command to identify regions with poor locality
> ---
>
> Key: HBASE-17973
> URL: https://issues.apache.org/jira/browse/HBASE-17973
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17973.001.patch, HBASE-17973.002.patch,
> HBASE-17973.003.patch, HBASE-17973.branch-1.001.patch
>
>
> The data locality of regions often plays a large role in the efficiency of
> HBase. Compactions are also expensive to execute, especially on very large
> tables. The balancer can do a good job trying to maintain locality (when
> tuned properly), but it is not perfect.
> This creates a less-than-desirable situation where it's a costly operation to
> take a cluster with spotty poor locality (e.g. a small percentage of
> regionservers with poor locality).
> We already have this information available via the {{ClusterStatus}} proto.
> We can easily write a shell command that can present regions which are
> lacking a certain percentage of locality.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17998) Improve HBase RPC write throttling size estimation
[
https://issues.apache.org/jira/browse/HBASE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001881#comment-16001881
]
Karan Mehta commented on HBASE-17998:
-
I did not find really feasible for this thing to happen because of following
reasons.
1. Calling {{getSerializedSize()}} on a Protobuf to estimate its size will
require to traverse over the complete protobuf data which we don't wanna do in
the first place.
2. Size of Puts can be estimated based on the number of bytes received for the
RPC Request. This information can be passed around with {{HBaseRpcController}}
class. However, it is difficult to estimate the size of only {{Puts}} in case
of a {{MultiRequest}} since we just have a total buffer size which may include
{{Gets}} and {{Scans}}. I am not sure if we should really be doing code changes
for just this support.
Rather than randomly estimating the size, a slightly better approach might be
to use a moving average based on the past requests that have been seen as
suggested by [~vincentpoon]. Lets discuss if there are any other ways to
accomplish this task.
> Improve HBase RPC write throttling size estimation
> --
>
> Key: HBASE-17998
> URL: https://issues.apache.org/jira/browse/HBASE-17998
> Project: HBase
> Issue Type: Improvement
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>
> Currently when RPC throttling, the size of each put is estimated using a
> hardcoded value 100 bytes. This can be improved by using the protobuf size as
> an estimate, without having to deserialize or do a big refactoring.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18017) Reduce frequency of setStoragePolicy failure warnings
[ https://issues.apache.org/jira/browse/HBASE-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001858#comment-16001858 ] Andrew Purtell commented on HBASE-18017: YDYT [~lhofhansl] ? > Reduce frequency of setStoragePolicy failure warnings > - > > Key: HBASE-18017 > URL: https://issues.apache.org/jira/browse/HBASE-18017 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18017.patch > > > When running with storage policy specification support if the underlying HDFS > doesn't support it or if it has been disabled in site configuration the > resulting logging is excessive. Log at WARN level once per FileSystem > instance. Otherwise, log messages at DEBUG level. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17924) Consider sorting the row order when processing multi() ops before taking rowlocks
[
https://issues.apache.org/jira/browse/HBASE-17924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-17924:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 1.4.0
Status: Resolved (was: Patch Available)
Pushed to master and branch-1.
> Consider sorting the row order when processing multi() ops before taking
> rowlocks
> -
>
> Key: HBASE-17924
> URL: https://issues.apache.org/jira/browse/HBASE-17924
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0, 1.1.8
>Reporter: Andrew Purtell
>Assignee: Allan Yang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17924.patch, HBASE-17924.v0.patch,
> HBASE-17924.v2.patch, HBASE-17924.v3.patch, HBASE-17924.v4.patch,
> HBASE-17924.v5.patch
>
>
> When processing a batch mutation, we take row locks in whatever order the
> mutations were added to the multi op by the client.
>
> {noformat}
> RSRpcServices#multi -> RSRpcServices#mutateRows -> HRegion#mutateRow ->
> HRegion#mutateRowsWithLocks -> HRegion#processRowsWithLocks
> {noformat}
> Or
> {noformat}
> RSRpcServices#multi -> RSRpcServices#doNonAtomicRegionMutation ->
> HRegion#get
> | HRegion#append
> | HRegion#increment
> | HRegionServer#doBatchOp -> HRegion#batchMutate ->
> HRegion#doMiniBatchMutation
> {noformat}
>
> multi() is fed by client APIs that accept a RowMutations object containing
> actions for multiple rows. The container for ops inside RowMutations is an
> ArrayList, which doesn't change the ordering of objects added to it. The
> protobuf implementation of the messages for multi ops do not reorder the list
> of actions. When processing multi ops we iterate over the actions in the
> order rehydrated from protobuf.
> We should discuss sorting the order of ops by row key when processing multi()
> ops before taking row locks. Does this make lock ordering more predictable
> for server side operations? Yes, but potentially surprising for the client,
> right? Is there any legitimate reason we should take locks out of row key
> sorted order because the client has structured the request as such?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[ https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001806#comment-16001806 ] Hudson commented on HBASE-18015: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2975 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2975/]) HBASE-18015 Storage class aware block placement for procedure v2 WALs (apurtell: rev 3dc38a4ff1210e662f3d08fe768def9b79f008e9) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java > Storage class aware block placement for procedure v2 WALs > - > > Key: HBASE-18015 > URL: https://issues.apache.org/jira/browse/HBASE-18015 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-18015.patch > > > After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class > placement policies for store files and WAL files. However, we missed > procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We > should apply the same storage policy for procv2 WALs as we do for > regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY > configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18016) Implement abort for TruncateTableProcedure
[ https://issues.apache.org/jira/browse/HBASE-18016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001723#comment-16001723 ] Umesh Agashe commented on HBASE-18016: -- bq. Currently, it is tricky and difficult (if not impossible) to undo deletions. [~syuanjiang], Thanks for your comments. I agree. Currently I am thinking that abort() can just abort/ kill the procedure with or without implementing rollback. We noticed that once in a while procedure gets stuck (in waiting state for an event thats never going to occur) and user can not do anything about it. Its stuck in the system forever. Implementing abort with or without rollback will help user clean up the stuck procedures. If procedure supports rollback, abort will trigger rollback or else user can manually cleanup after abort. Let me know your thoughts. > Implement abort for TruncateTableProcedure > -- > > Key: HBASE-18016 > URL: https://issues.apache.org/jira/browse/HBASE-18016 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0 > > > TruncateTableProcedure can not be aborted as abort is not implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17210) Set timeout on trying rowlock according to client's RPC timeout
[ https://issues.apache.org/jira/browse/HBASE-17210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001696#comment-16001696 ] stack commented on HBASE-17210: --- [~yangzhe1991] What brought about this change? Were you experiencing contention on a row? Asking because seeing something where all handlers are blocked trying to get a lock but weirdly no handler seems to have the lock; i.e. no one is doing work. > Set timeout on trying rowlock according to client's RPC timeout > --- > > Key: HBASE-17210 > URL: https://issues.apache.org/jira/browse/HBASE-17210 > Project: HBase > Issue Type: Sub-task >Reporter: Phil Yang >Assignee: Phil Yang > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-17120.v1.patch, HBASE-17210.branch-1.v01.patch, > HBASE-17210.branch-1.v02.patch, HBASE-17210.branch-1.v03.patch, > HBASE-17210.v02.patch, HBASE-17210.v03.patch, HBASE-17210.v04.patch, > HBASE-17210.v04.patch > > > Now when we want to get a row lock, the timeout is fixed and default is 30s. > But the requests from client have different RPC timeout setting. We can use > the client's deadline to set timeout on tryLock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-18017) Reduce frequency of setStoragePolicy failure warnings
[ https://issues.apache.org/jira/browse/HBASE-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18017: --- Status: Patch Available (was: Open) > Reduce frequency of setStoragePolicy failure warnings > - > > Key: HBASE-18017 > URL: https://issues.apache.org/jira/browse/HBASE-18017 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18017.patch > > > When running with storage policy specification support if the underlying HDFS > doesn't support it or if it has been disabled in site configuration the > resulting logging is excessive. Log at WARN level once per FileSystem > instance. Otherwise, log messages at DEBUG level. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-18017) Reduce frequency of setStoragePolicy failure warnings
[ https://issues.apache.org/jira/browse/HBASE-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18017: --- Attachment: HBASE-18017.patch Attach patch implements one log at WARN level for a setStoragePolicy failure for each FileSystem object instance with all subsequent messages at DEBUG level. > Reduce frequency of setStoragePolicy failure warnings > - > > Key: HBASE-18017 > URL: https://issues.apache.org/jira/browse/HBASE-18017 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18017.patch > > > When running with storage policy specification support if the underlying HDFS > doesn't support it or if it has been disabled in site configuration the > resulting logging is excessive. Log at WARN level once per FileSystem > instance. Otherwise, log messages at DEBUG level. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18017) Reduce frequency of setStoragePolicy failure warnings
Andrew Purtell created HBASE-18017: -- Summary: Reduce frequency of setStoragePolicy failure warnings Key: HBASE-18017 URL: https://issues.apache.org/jira/browse/HBASE-18017 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor When running with storage policy specification support if the underlying HDFS doesn't support it or if it has been disabled in site configuration the resulting logging is excessive. Log at WARN level once per FileSystem instance. Otherwise, log messages at DEBUG level. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18016) Implement abort for TruncateTableProcedure
[ https://issues.apache.org/jira/browse/HBASE-18016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001593#comment-16001593 ] Stephen Yuan Jiang commented on HBASE-18016: Currently, it is tricky and difficult (if not impossible) to undo deletions. That is why DeleteTableProcedure and TruncateTableProcedure has no rollback once starting. > Implement abort for TruncateTableProcedure > -- > > Key: HBASE-18016 > URL: https://issues.apache.org/jira/browse/HBASE-18016 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0 > > > TruncateTableProcedure can not be aborted as abort is not implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17343) Make Compacting Memstore default in 2.0 with BASIC as the default type
[
https://issues.apache.org/jira/browse/HBASE-17343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001588#comment-16001588
]
Hadoop QA commented on HBASE-17343:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 35s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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} 8m
4s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 38s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 13s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s {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}
54m 58s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m 26s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 138m 2s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.master.locking.TestLockManager |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866970/HBASE-17343-V08.patch
|
| JIRA Issue | HBASE-17343 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 73b96c34a28b 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 0d0ccc3 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6732/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/6732/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6732/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6732/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Make
[jira] [Updated] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[ https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18015: --- Fix Version/s: 2.0.0 > Storage class aware block placement for procedure v2 WALs > - > > Key: HBASE-18015 > URL: https://issues.apache.org/jira/browse/HBASE-18015 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-18015.patch > > > After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class > placement policies for store files and WAL files. However, we missed > procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We > should apply the same storage policy for procv2 WALs as we do for > regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY > configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[ https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18015: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master. Thanks for the reviews > Storage class aware block placement for procedure v2 WALs > - > > Key: HBASE-18015 > URL: https://issues.apache.org/jira/browse/HBASE-18015 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18015.patch > > > After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class > placement policies for store files and WAL files. However, we missed > procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We > should apply the same storage policy for procv2 WALs as we do for > regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY > configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14070) Hybrid Logical Clocks for HBase
[ https://issues.apache.org/jira/browse/HBASE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001526#comment-16001526 ] stack commented on HBASE-14070: --- Thanks for update [~churromorales] Will return here if have any new status sir. > Hybrid Logical Clocks for HBase > --- > > Key: HBASE-14070 > URL: https://issues.apache.org/jira/browse/HBASE-14070 > Project: HBase > Issue Type: New Feature >Reporter: Enis Soztutar >Assignee: churro morales > Attachments: HBASE-14070.master.001.patch, > HybridLogicalClocksforHBaseandPhoenix.docx, > HybridLogicalClocksforHBaseandPhoenix.pdf > > > HBase and Phoenix uses systems physical clock (PT) to give timestamps to > events (read and writes). This works mostly when the system clock is strictly > monotonically increasing and there is no cross-dependency between servers > clocks. However we know that leap seconds, general clock skew and clock drift > are in fact real. > This jira proposes using Hybrid Logical Clocks (HLC) as an implementation of > hybrid physical clock + a logical clock. HLC is best of both worlds where it > keeps causality relationship similar to logical clocks, but still is > compatible with NTP based physical system clock. HLC can be represented in > 64bits. > A design document is attached and also can be found here: > https://docs.google.com/document/d/1LL2GAodiYi0waBz5ODGL4LDT4e_bXy8P9h6kWC05Bhw/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14070) Hybrid Logical Clocks for HBase
[ https://issues.apache.org/jira/browse/HBASE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001520#comment-16001520 ] churro morales commented on HBASE-14070: [~stack] Sorry haven't had much time to work on this feature. If anyone else is interested by all means they should take it. Might have time in a month but that might be too late. > Hybrid Logical Clocks for HBase > --- > > Key: HBASE-14070 > URL: https://issues.apache.org/jira/browse/HBASE-14070 > Project: HBase > Issue Type: New Feature >Reporter: Enis Soztutar >Assignee: churro morales > Attachments: HBASE-14070.master.001.patch, > HybridLogicalClocksforHBaseandPhoenix.docx, > HybridLogicalClocksforHBaseandPhoenix.pdf > > > HBase and Phoenix uses systems physical clock (PT) to give timestamps to > events (read and writes). This works mostly when the system clock is strictly > monotonically increasing and there is no cross-dependency between servers > clocks. However we know that leap seconds, general clock skew and clock drift > are in fact real. > This jira proposes using Hybrid Logical Clocks (HLC) as an implementation of > hybrid physical clock + a logical clock. HLC is best of both worlds where it > keeps causality relationship similar to logical clocks, but still is > compatible with NTP based physical system clock. HLC can be represented in > 64bits. > A design document is attached and also can be found here: > https://docs.google.com/document/d/1LL2GAodiYi0waBz5ODGL4LDT4e_bXy8P9h6kWC05Bhw/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17489) ClientScanner may send a next request to a RegionScanner which has been exhausted
[
https://issues.apache.org/jira/browse/HBASE-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001480#comment-16001480
]
Benoit Sigoure commented on HBASE-17489:
AsyncHBase expects the scanner ID in response to scanning more rows but that's
not actually necessary. I think I added this as a sanity check because I
expected the server to always return the ID, but as was said above it's
technically not strictly necessary for the server to return the ID on
subsequent uses of the scanner.
The code doesn't even do anything with the scanner ID other than checking that
it's the ID we expected:
{code}
@Override
Response deserialize(final ChannelBuffer buf, final int cell_size) {
final ScanResponse resp = readProtobuf(buf, ScanResponse.PARSER);
final long id = resp.getScannerId();
if (scanner_id != id) {
throw new InvalidResponseException("Scan RPC response was for scanner"
+ " ID " + id + " but we expected"
+ scanner_id, resp);
}
final ArrayList rows = getRows(resp, buf, cell_size);
if (rows == null) {
return null;
}
return new Response(resp.getScannerId(), rows, resp.getMoreResults());
}
{code}
I guess we could fix this by saying "if we have a scanner ID in the response
THEN it must match the one expect" instead of "there must be a scanner ID in
the response that matches what we expect".
Ironically we had the same bug in GoHBase, where we made the same assumption
that the scanner ID was always present in the response.
> ClientScanner may send a next request to a RegionScanner which has been
> exhausted
> -
>
> Key: HBASE-17489
> URL: https://issues.apache.org/jira/browse/HBASE-17489
> Project: HBase
> Issue Type: Bug
> Components: Client, scan
>Affects Versions: 2.0.0, 1.3.0, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17489-branch-1.3.patch,
> HBASE-17489-branch-1.patch, HBASE-17489.patch, HBASE-17489-v1.patch,
> HBASE-17489-v2.patch, HBASE-17489-v3.patch, HBASE-17489-v4.patch,
> HBASE-17489-v4.patch, HBASE-17489-v5.patch, HBASE-17489-v6.patch
>
>
> Found it when implementing HBASE-17045. Seems the final result of the scan is
> correct but no doubt the logic is broken. We need to fix it to stop things
> get worse in the future.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[
https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001421#comment-16001421
]
Hadoop QA commented on HBASE-18015:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 10m 44s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{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
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {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 58s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 106m 47s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 154m 8s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866947/HBASE-18015.patch |
| JIRA Issue | HBASE-18015 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux dac95a3cd0fd 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 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 / 0d0ccc3 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6731/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6731/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6731/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Storage class aware block placement for procedure v2 WALs
> -
>
> Key: HBASE-18015
> URL: https://issues.apache.org/jira/browse/HBASE-18015
> Project:
[jira] [Commented] (HBASE-17887) TestAcidGuarantees fails frequently
[
https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001416#comment-16001416
]
Hadoop QA commented on HBASE-17887:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 30s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 22s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s {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} 4m 5s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 19s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 19s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
54m 59s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 4m 32s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 209m 52s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
32s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 291m 5s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| |
org.apache.hadoop.hbase.regionserver.StoreScanner.updateReaders(Store$ScannerTicket)
does not release lock on all exception paths At StoreScanner.java:on all
exception paths At StoreScanner.java:[line 812] |
| Failed junit tests | hadoop.hbase.master.balancer.TestStochasticLoadBalancer2
|
| | hadoop.hbase.client.TestAsyncTableAdminApi |
| Timed out junit tests | org.apache.hadoop.hbase.snapshot.TestExportSnapshot |
| | org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866901/HBASE-17887.v2.patch |
| JIRA Issue | HBASE-17887 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 1e39601e6b70 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 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 / 0d0ccc3 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| findbugs |
https://builds.apache.org/job/PreCommit-HBASE-Build/6726/artifact/patchprocess/new-findbugs-hbase-server.html
|
| unit |
[jira] [Updated] (HBASE-17343) Make Compacting Memstore default in 2.0 with BASIC as the default type
[ https://issues.apache.org/jira/browse/HBASE-17343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anastasia Braginsky updated HBASE-17343: Attachment: HBASE-17343-V08.patch > Make Compacting Memstore default in 2.0 with BASIC as the default type > -- > > Key: HBASE-17343 > URL: https://issues.apache.org/jira/browse/HBASE-17343 > Project: HBase > Issue Type: New Feature > Components: regionserver >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: Anastasia Braginsky >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-17343-V01.patch, HBASE-17343-V02.patch, > HBASE-17343-V04.patch, HBASE-17343-V05.patch, HBASE-17343-V06.patch, > HBASE-17343-V07.patch, HBASE-17343-V08.patch > > > FYI [~anastas], [~eshcar] and [~ebortnik]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14070) Hybrid Logical Clocks for HBase
[ https://issues.apache.org/jira/browse/HBASE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001278#comment-16001278 ] stack commented on HBASE-14070: --- [~churromorales] Any luck here boss? Might have someone else interested in moving this forward. > Hybrid Logical Clocks for HBase > --- > > Key: HBASE-14070 > URL: https://issues.apache.org/jira/browse/HBASE-14070 > Project: HBase > Issue Type: New Feature >Reporter: Enis Soztutar >Assignee: churro morales > Attachments: HBASE-14070.master.001.patch, > HybridLogicalClocksforHBaseandPhoenix.docx, > HybridLogicalClocksforHBaseandPhoenix.pdf > > > HBase and Phoenix uses systems physical clock (PT) to give timestamps to > events (read and writes). This works mostly when the system clock is strictly > monotonically increasing and there is no cross-dependency between servers > clocks. However we know that leap seconds, general clock skew and clock drift > are in fact real. > This jira proposes using Hybrid Logical Clocks (HLC) as an implementation of > hybrid physical clock + a logical clock. HLC is best of both worlds where it > keeps causality relationship similar to logical clocks, but still is > compatible with NTP based physical system clock. HLC can be represented in > 64bits. > A design document is attached and also can be found here: > https://docs.google.com/document/d/1LL2GAodiYi0waBz5ODGL4LDT4e_bXy8P9h6kWC05Bhw/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16196) Update jruby to a newer version.
[
https://issues.apache.org/jira/browse/HBASE-16196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001270#comment-16001270
]
Mike Drob commented on HBASE-16196:
---
bq. Can we continue to ship a complete jruby jar?
Yea, we can ship all of those, assuming I don't find anything else. EPL and
Ruby License are both on the [Category
B|https://www.apache.org/legal/resolved.html#category-b] list. The JRuby works
are tri-licensed and explicitly called out as acceptable in the next question
on that page as well.
bq. Out of interest, how much as the jruby complete grown since 1.6.x?
{noformat}
-rw-rw-r-- 1 mdrob mdrob 14M Nov 4 2014 jruby-complete-1.6.8.jar
-rw-rw-r-- 1 mdrob mdrob 22M Jun 8 2016 jruby-complete-1.7.17.jar
-rw-rw-r-- 1 mdrob mdrob 22M May 1 14:19 jruby-complete-9.1.8.0.jar
{noformat}
+8M since 1.6.8, but most of that came in 1.7.x so there's not anything to be
gained with a smaller version increment in terms of size.
> Update jruby to a newer version.
>
>
> Key: HBASE-16196
> URL: https://issues.apache.org/jira/browse/HBASE-16196
> Project: HBase
> Issue Type: Bug
> Components: dependencies, shell
>Reporter: Elliott Clark
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0, 1.5.0
>
> Attachments: 0001-Update-to-JRuby-9.1.2.0-and-JLine-2.12.patch,
> hbase-16196.branch-1.patch, hbase-16196.v2.branch-1.patch,
> hbase-16196.v3.branch-1.patch, hbase-16196.v4.branch-1.patch,
> HBASE-16196.v5.patch, HBASE-16196.v6.patch
>
>
> Ruby 1.8.7 is no longer maintained.
> The TTY library in the old jruby is bad. The newer one is less bad.
> Since this is only a dependency on the hbase-shell module and not on
> hbase-client or hbase-server this should be a pretty simple thing that
> doesn't have any backwards compat issues.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16196) Update jruby to a newer version.
[ https://issues.apache.org/jira/browse/HBASE-16196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001237#comment-16001237 ] stack commented on HBASE-16196: --- Some of those licenses look frightening [~mdrob] Can we continue to ship a complete jruby jar? Out of interest, how much as the jruby complete grown since 1.6.x? Thanks sir. > Update jruby to a newer version. > > > Key: HBASE-16196 > URL: https://issues.apache.org/jira/browse/HBASE-16196 > Project: HBase > Issue Type: Bug > Components: dependencies, shell >Reporter: Elliott Clark >Assignee: Mike Drob >Priority: Critical > Fix For: 2.0.0, 1.5.0 > > Attachments: 0001-Update-to-JRuby-9.1.2.0-and-JLine-2.12.patch, > hbase-16196.branch-1.patch, hbase-16196.v2.branch-1.patch, > hbase-16196.v3.branch-1.patch, hbase-16196.v4.branch-1.patch, > HBASE-16196.v5.patch, HBASE-16196.v6.patch > > > Ruby 1.8.7 is no longer maintained. > The TTY library in the old jruby is bad. The newer one is less bad. > Since this is only a dependency on the hbase-shell module and not on > hbase-client or hbase-server this should be a pretty simple thing that > doesn't have any backwards compat issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18016) Implement abort for TruncateTableProcedure
Umesh Agashe created HBASE-18016: Summary: Implement abort for TruncateTableProcedure Key: HBASE-18016 URL: https://issues.apache.org/jira/browse/HBASE-18016 Project: HBase Issue Type: Sub-task Components: proc-v2 Reporter: Umesh Agashe Assignee: Umesh Agashe TruncateTableProcedure can not be aborted as abort is not implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001209#comment-16001209 ] ramkrishna.s.vasudevan commented on HBASE-17887: Let me use the 17887.ut.patch and report back. bq.The main aim here is to fix the ACID. The broken ACID in both of branch-1 and master are due to the lost active memstore so i think that there is no extra issue currently. Ok. No problem. > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, > HBASE-17887.v2.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17887) TestAcidGuarantees fails frequently
[
https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001205#comment-16001205
]
Chia-Ping Tsai commented on HBASE-17887:
{code}
try {
// wait for the flush, the thread will be blocked in
HStore#notifyChangedReadersObservers.
s.awaitTermination(500, TimeUnit.MILLISECONDS);
} catch (InterruptedException ex) {
}
{code}
[~ram_krish] Would you please increase the wait time and retry the ut.patch?
> TestAcidGuarantees fails frequently
> ---
>
> Key: HBASE-17887
> URL: https://issues.apache.org/jira/browse/HBASE-17887
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Umesh Agashe
>Assignee: Chia-Ping Tsai
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1
>
> Attachments: HBASE-17887.branch-1.v0.patch,
> HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch,
> HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch,
> HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch,
> HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch,
> HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch,
> HBASE-17887.v2.patch
>
>
> As per the flaky tests dashboard here:
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html,
> It fails 30% of the time.
> While working on HBASE-17863, a few verification builds on patch failed due
> to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are
> unlikely to affect get/ put path.
> I ran the test with and without the patch several times locally and found
> that TestAcidGuarantees fails without the patch similar number of times.
> Opening blocker, considering acid guarantees are critical to HBase.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17887) TestAcidGuarantees fails frequently
[
https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001193#comment-16001193
]
Ted Yu commented on HBASE-17887:
I can reproduce the test failure using 17887.ut.patch :
{code}
testScanWithDoubleFlush(org.apache.hadoop.hbase.regionserver.TestStore) Time
elapsed: 1.428 sec <<< FAILURE!
java.lang.AssertionError: expected:currentValue, actual:oldValue
at
org.apache.hadoop.hbase.regionserver.TestStore.testScanWithDoubleFlush(TestStore.java:1020)
{code}
> TestAcidGuarantees fails frequently
> ---
>
> Key: HBASE-17887
> URL: https://issues.apache.org/jira/browse/HBASE-17887
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Umesh Agashe
>Assignee: Chia-Ping Tsai
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1
>
> Attachments: HBASE-17887.branch-1.v0.patch,
> HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch,
> HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch,
> HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch,
> HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch,
> HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch,
> HBASE-17887.v2.patch
>
>
> As per the flaky tests dashboard here:
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html,
> It fails 30% of the time.
> While working on HBASE-17863, a few verification builds on patch failed due
> to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are
> unlikely to affect get/ put path.
> I ran the test with and without the patch several times locally and found
> that TestAcidGuarantees fails without the patch similar number of times.
> Opening blocker, considering acid guarantees are critical to HBase.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[ https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001179#comment-16001179 ] Ted Yu commented on HBASE-18015: lgtm > Storage class aware block placement for procedure v2 WALs > - > > Key: HBASE-18015 > URL: https://issues.apache.org/jira/browse/HBASE-18015 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18015.patch > > > After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class > placement policies for store files and WAL files. However, we missed > procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We > should apply the same storage policy for procv2 WALs as we do for > regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY > configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001177#comment-16001177 ] Chia-Ping Tsai commented on HBASE-17887: bq. If you feel there are more issues The main aim here is to fix the ACID. The broken ACID in both of branch-1 and master are due to the lost active memstore so i think that there is no extra issue currently. bq. I tried multiple times but I could not get the error. Will look into once again. It is vary weird. The [QA|https://builds.apache.org/job/PreCommit-HBASE-Build/6722/artifact/patchprocess/patch-unit-hbase-server.txt] also get the error through the ut.patch. I will run the UT in different environment. Thanks for your comments. [~ram_krish] > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, > HBASE-17887.v2.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[ https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001174#comment-16001174 ] Jerry He commented on HBASE-18015: -- +1 > Storage class aware block placement for procedure v2 WALs > - > > Key: HBASE-18015 > URL: https://issues.apache.org/jira/browse/HBASE-18015 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18015.patch > > > After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class > placement policies for store files and WAL files. However, we missed > procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We > should apply the same storage policy for procv2 WALs as we do for > regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY > configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001118#comment-16001118 ] ramkrishna.s.vasudevan commented on HBASE-17887: I tried multiple times but I could not get the error. Will look into once again. If you feel there are more issues, suggest you raise a seperate JIRA for the issue and attach patches there. So that the problem statement is clear. Then once all JIRAs are resolved automatically this TestAcidGuaratees will pass and we can close this JIRA linking to them. I think a seperate issue will also draw more attention as this JIRA title indicates more of a test case issue. > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, > HBASE-17887.v2.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[ https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18015: --- Status: Patch Available (was: Open) > Storage class aware block placement for procedure v2 WALs > - > > Key: HBASE-18015 > URL: https://issues.apache.org/jira/browse/HBASE-18015 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18015.patch > > > After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class > placement policies for store files and WAL files. However, we missed > procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We > should apply the same storage policy for procv2 WALs as we do for > regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY > configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
[ https://issues.apache.org/jira/browse/HBASE-18015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18015: --- Attachment: HBASE-18015.patch > Storage class aware block placement for procedure v2 WALs > - > > Key: HBASE-18015 > URL: https://issues.apache.org/jira/browse/HBASE-18015 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-18015.patch > > > After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class > placement policies for store files and WAL files. However, we missed > procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We > should apply the same storage policy for procv2 WALs as we do for > regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY > configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18015) Storage class aware block placement for procedure v2 WALs
Andrew Purtell created HBASE-18015: -- Summary: Storage class aware block placement for procedure v2 WALs Key: HBASE-18015 URL: https://issues.apache.org/jira/browse/HBASE-18015 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor After HBASE-14061, HBASE-15172, and HBASE-17538, we can specify storage class placement policies for store files and WAL files. However, we missed procedure v2 WALs aka "MasterProcWAL", opened and updated by the master. We should apply the same storage policy for procv2 WALs as we do for regionserver WALs, specified by the HConstants.WAL_STORAGE_POLICY configuration key, using HConstants.DEFAULT_WAL_STORAGE_POLICY as default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[
https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001036#comment-16001036
]
Hadoop QA commented on HBASE-17906:
---
| (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 12s {color}
| {color:red} HBASE-17906 does not apply to 0.98. 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/12866932/HBASE-17906.branch-0.98.0008.patch
|
| JIRA Issue | HBASE-17906 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6730/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
>
>
> Key: HBASE-17906
> URL: https://issues.apache.org/jira/browse/HBASE-17906
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
> Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77
>Reporter: Albert Lee
> Labels: patch
> Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
>
> Attachments: HBASE-17906.branch-0.98.0005.patch,
> HBASE-17906.branch-0.98.0006.patch, HBASE-17906.branch-0.98.0007.patch,
> HBASE-17906.branch-0.98.0008.patch, HBASE-17906.master.001.patch,
> HBASE-17906.master.002.patch
>
>
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16196) Update jruby to a newer version.
[ https://issues.apache.org/jira/browse/HBASE-16196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001030#comment-16001030 ] Mike Drob commented on HBASE-16196: --- This will be much easier after JRuby updates their files - I've filed and started work on this issue over on the JRuby project - https://github.com/jruby/jruby/issues/4587 > Update jruby to a newer version. > > > Key: HBASE-16196 > URL: https://issues.apache.org/jira/browse/HBASE-16196 > Project: HBase > Issue Type: Bug > Components: dependencies, shell >Reporter: Elliott Clark >Assignee: Mike Drob >Priority: Critical > Fix For: 2.0.0, 1.5.0 > > Attachments: 0001-Update-to-JRuby-9.1.2.0-and-JLine-2.12.patch, > hbase-16196.branch-1.patch, hbase-16196.v2.branch-1.patch, > hbase-16196.v3.branch-1.patch, hbase-16196.v4.branch-1.patch, > HBASE-16196.v5.patch, HBASE-16196.v6.patch > > > Ruby 1.8.7 is no longer maintained. > The TTY library in the old jruby is bad. The newer one is less bad. > Since this is only a dependency on the hbase-shell module and not on > hbase-client or hbase-server this should be a pretty simple thing that > doesn't have any backwards compat issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[
https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001022#comment-16001022
]
Hadoop QA commented on HBASE-17906:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 22m 56s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 16s {color}
| {color:red} HBASE-17906 does not apply to 0.98. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:ef91163 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866932/HBASE-17906.branch-0.98.0008.patch
|
| JIRA Issue | HBASE-17906 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6728/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
>
>
> Key: HBASE-17906
> URL: https://issues.apache.org/jira/browse/HBASE-17906
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
> Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77
>Reporter: Albert Lee
> Labels: patch
> Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
>
> Attachments: HBASE-17906.branch-0.98.0005.patch,
> HBASE-17906.branch-0.98.0006.patch, HBASE-17906.branch-0.98.0007.patch,
> HBASE-17906.branch-0.98.0008.patch, HBASE-17906.master.001.patch,
> HBASE-17906.master.002.patch
>
>
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Status: Patch Available (was: Open) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.24, 0.98.23, 0.98.22, 0.98.21, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.25, 0.98.24, 0.98.23, 0.98.22, 0.98.21 > > Attachments: HBASE-17906.branch-0.98.0005.patch, > HBASE-17906.branch-0.98.0006.patch, HBASE-17906.branch-0.98.0007.patch, > HBASE-17906.branch-0.98.0008.patch, HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: HBASE-17906.branch-0.98.0008.patch > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.0005.patch, > HBASE-17906.branch-0.98.0006.patch, HBASE-17906.branch-0.98.0007.patch, > HBASE-17906.branch-0.98.0008.patch, HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.0004.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.0005.patch, > HBASE-17906.branch-0.98.0006.patch, HBASE-17906.branch-0.98.0007.patch, > HBASE-17906.master.001.patch, HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: HBASE-17906.branch-0.98.0007.patch HBASE-17906.branch-0.98.0006.patch HBASE-17906.branch-0.98.0005.patch > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.0005.patch, > HBASE-17906.branch-0.98.0006.patch, HBASE-17906.branch-0.98.0007.patch, > HBASE-17906.master.001.patch, HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.0002.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.0004.patch, > HBASE-17906.master.001.patch, HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.0003.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.0004.patch, > HBASE-17906.master.001.patch, HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.0001.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.0002.patch, > HBASE-17906.branch-0.98.0003.patch, HBASE-17906.branch-0.98.0004.patch, > HBASE-17906.master.001.patch, HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Status: Open (was: Patch Available) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.24, 0.98.23, 0.98.22, 0.98.21, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.25, 0.98.24, 0.98.23, 0.98.22, 0.98.21 > > Attachments: HBASE-17906.branch-0.98.0002.patch, > HBASE-17906.branch-0.98.0003.patch, HBASE-17906.branch-0.98.0004.patch, > HBASE-17906.master.001.patch, HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Status: Patch Available (was: Open) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.24, 0.98.23, 0.98.22, 0.98.21, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.25, 0.98.24, 0.98.23, 0.98.22, 0.98.21 > > Attachments: HBASE-17906.branch-0.98.0001.patch, > HBASE-17906.branch-0.98.0002.patch, HBASE-17906.branch-0.98.0003.patch, > HBASE-17906.branch-0.98.0004.patch, HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Status: Open (was: Patch Available) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.24, 0.98.23, 0.98.22, 0.98.21, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.25, 0.98.24, 0.98.23, 0.98.22, 0.98.21 > > Attachments: HBASE-17906.branch-0.98.0001.patch, > HBASE-17906.branch-0.98.0002.patch, HBASE-17906.branch-0.98.0003.patch, > HBASE-17906.branch-0.98.0004.patch, HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[
https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001002#comment-16001002
]
Hadoop QA commented on HBASE-17906:
---
| (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 9s {color}
| {color:red} HBASE-17906 does not apply to 0.98. 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/12866927/HBASE-17906.branch-0.98.0004.patch
|
| JIRA Issue | HBASE-17906 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6729/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
>
>
> Key: HBASE-17906
> URL: https://issues.apache.org/jira/browse/HBASE-17906
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
> Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77
>Reporter: Albert Lee
> Labels: patch
> Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
>
> Attachments: HBASE-17906.branch-0.98.0001.patch,
> HBASE-17906.branch-0.98.0002.patch, HBASE-17906.branch-0.98.0003.patch,
> HBASE-17906.branch-0.98.0004.patch, HBASE-17906.master.001.patch,
> HBASE-17906.master.002.patch
>
>
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: HBASE-17906.branch-0.98.0004.patch HBASE-17906.branch-0.98.0003.patch HBASE-17906.branch-0.98.0002.patch HBASE-17906.branch-0.98.0001.patch > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.0001.patch, > HBASE-17906.branch-0.98.0002.patch, HBASE-17906.branch-0.98.0003.patch, > HBASE-17906.branch-0.98.0004.patch, HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18014) A case of Region remain unassigned when table enabled
[
https://issues.apache.org/jira/browse/HBASE-18014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000986#comment-16000986
]
Hadoop QA commented on HBASE-18014:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m 23s
{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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
18s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} branch-1 passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 58s
{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 31s
{color} | {color:green} branch-1 passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 36s {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
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0_131 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 104m 32s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 154m 53s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRSKilledWhenInitializing |
| | hadoop.hbase.client.TestAdmin2 |
| | hadoop.hbase.trace.TestHTraceHooks |
| | hadoop.hbase.replication.TestSerialReplication |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:58c504e |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866890/HBASE-18014-branch-1.patch
|
| JIRA Issue | HBASE-18014 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux b49dade2c5ea 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.001.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18001) Extend the "count" shell command to support specified conditions
[
https://issues.apache.org/jira/browse/HBASE-18001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000957#comment-16000957
]
Guangxu Cheng commented on HBASE-18001:
---
{quote}
We can go with STARTROW, STOPROW, FILTER and COLUMNS...
Guangxu Cheng is this something you are going to work on?
{quote}
yep, I'm working on this. Thanks for your suggestion. patch will be coming
soon.Thanks
> Extend the "count" shell command to support specified conditions
>
>
> Key: HBASE-18001
> URL: https://issues.apache.org/jira/browse/HBASE-18001
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0
>
>
> shell command "count" can only count the number of rows in a table.
> And, it could not count the number of the specified conditions.
> Can we allow users to specified conditions like command "scan"?
> In that case, we can count the number of rows under any conditions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: HBASE-17906.branch-0.98.001.patch > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.001.patch, > HBASE-17906.master.001.patch, HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.003.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.001.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.002.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.004.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[
https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000955#comment-16000955
]
Hadoop QA commented on HBASE-17906:
---
| (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 12s {color}
| {color:red} HBASE-17906 does not apply to 0.98. 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/12866913/HBASE-17906.branch-0.98.004.patch
|
| JIRA Issue | HBASE-17906 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6727/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
>
>
> Key: HBASE-17906
> URL: https://issues.apache.org/jira/browse/HBASE-17906
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
> Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77
>Reporter: Albert Lee
> Labels: patch
> Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25
>
> Attachments: HBASE-17906.branch-0.98.001.patch,
> HBASE-17906.branch-0.98.002.patch, HBASE-17906.branch-0.98.003.patch,
> HBASE-17906.branch-0.98.004.patch, HBASE-17906.master.001.patch,
> HBASE-17906.master.002.patch
>
>
> When a huge amount of data writing to hbase through thrift2, there will be a
> deadlock error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: HBASE-17906.branch-0.98.004.patch HBASE-17906.branch-0.98.003.patch HBASE-17906.branch-0.98.002.patch HBASE-17906.branch-0.98.001.patch > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.branch-0.98.001.patch, > HBASE-17906.branch-0.98.002.patch, HBASE-17906.branch-0.98.003.patch, > HBASE-17906.branch-0.98.004.patch, HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: HBASE-17906.branch-0.98.004.patch) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17906) When a huge amount of data writing to hbase through thrift2, there will be a deadlock error.
[ https://issues.apache.org/jira/browse/HBASE-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee updated HBASE-17906: --- Attachment: (was: hbase-thrift-17906-ForRecurr.zip) > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. > > > Key: HBASE-17906 > URL: https://issues.apache.org/jira/browse/HBASE-17906 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > Environment: hadoop 2.5.2, hbase 0.98.20 jdk1.8.0_77 >Reporter: Albert Lee > Labels: patch > Fix For: 0.98.21, 0.98.22, 0.98.23, 0.98.24, 0.98.25 > > Attachments: HBASE-17906.master.001.patch, > HBASE-17906.master.002.patch > > > When a huge amount of data writing to hbase through thrift2, there will be a > deadlock error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18009) Move RpcServer.Call to a separated file
[
https://issues.apache.org/jira/browse/HBASE-18009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000898#comment-16000898
]
Hadoop QA commented on HBASE-18009:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 10m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {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.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 111m 58s
{color} | {color:green} hbase-server in the patch passed. {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} 161m 58s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866886/HBASE-18009-v1.patch |
| JIRA Issue | HBASE-18009 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux a6552ea47e9b 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017 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 / 0d0ccc3 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6723/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6723/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Move RpcServer.Call to a separated file
> ---
>
> Key: HBASE-18009
> URL: https://issues.apache.org/jira/browse/HBASE-18009
> Project: HBase
> Issue Type: Sub-task
> Components: IPC/RPC
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-18009.patch, HBASE-18009-v1.patch
>
>
> For
[jira] [Commented] (HBASE-11013) Clone Snapshots on Secure Cluster Should provide option to apply Retained User Permissions
[
https://issues.apache.org/jira/browse/HBASE-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000872#comment-16000872
]
Hadoop QA commented on HBASE-11013:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m 5s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 27s
{color} | {color:blue} Maven dependency ordering for branch {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} 1m 20s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
30s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 57s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} master passed {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
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s {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}
26m 17s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 25s
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 25s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 26m 54s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 98m 15s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestCheckTestClasses |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866888/HBASE-11013.v1.patch |
| JIRA Issue | HBASE-11013 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile cc hbaseprotoc |
| uname | Linux 4abbb3b465f6 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-18001) Extend the "count" shell command to support specified conditions
[ https://issues.apache.org/jira/browse/HBASE-18001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000856#comment-16000856 ] Jean-Marc Spaggiari commented on HBASE-18001: - We can go with STARTROW, STOPROW, FILTER and COLUMNS... [~andrewcheng] is this something you are going to work on? > Extend the "count" shell command to support specified conditions > > > Key: HBASE-18001 > URL: https://issues.apache.org/jira/browse/HBASE-18001 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 2.0.0 >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Minor > Labels: beginner > Fix For: 2.0.0 > > > shell command "count" can only count the number of rows in a table. > And, it could not count the number of the specified conditions. > Can we allow users to specified conditions like command "scan"? > In that case, we can count the number of rows under any conditions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17887) TestAcidGuarantees fails frequently
[
https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-17887:
---
Attachment: HBASE-17887.v2.patch
master.v2.patch - -
add a UT(TestStore#testCreateScannerAndSnapshotConcurrently) to trigger the
following bug.
{noformat}
We will lose the latest segment when creating the scanner with the following
execution order.
1) List pipelineList = pipeline.getSegments(); // getScanners
2) pipeline.pushHead(active); // pushActiveToPipeline
3) resetActive(); // pushActiveToPipeline
4) order = addToScanners(active, readPt, order, list); // getScanners
{noformat}
> TestAcidGuarantees fails frequently
> ---
>
> Key: HBASE-17887
> URL: https://issues.apache.org/jira/browse/HBASE-17887
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Umesh Agashe
>Assignee: Chia-Ping Tsai
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1
>
> Attachments: HBASE-17887.branch-1.v0.patch,
> HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch,
> HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch,
> HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch,
> HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch,
> HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch,
> HBASE-17887.v2.patch
>
>
> As per the flaky tests dashboard here:
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html,
> It fails 30% of the time.
> While working on HBASE-17863, a few verification builds on patch failed due
> to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are
> unlikely to affect get/ put path.
> I ran the test with and without the patch several times locally and found
> that TestAcidGuarantees fails without the patch similar number of times.
> Opening blocker, considering acid guarantees are critical to HBase.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17887: --- Status: Patch Available (was: Open) > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, > HBASE-17887.v2.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17887) TestAcidGuarantees fails frequently
[ https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-17887: --- Status: Open (was: Patch Available) > TestAcidGuarantees fails frequently > --- > > Key: HBASE-17887 > URL: https://issues.apache.org/jira/browse/HBASE-17887 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.4.1 > > Attachments: HBASE-17887.branch-1.v0.patch, > HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, > HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, > HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, > HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch > > > As per the flaky tests dashboard here: > https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html, > It fails 30% of the time. > While working on HBASE-17863, a few verification builds on patch failed due > to TestAcidGuarantees didn't pass. IMHO, the changes for HBASE-17863 are > unlikely to affect get/ put path. > I ran the test with and without the patch several times locally and found > that TestAcidGuarantees fails without the patch similar number of times. > Opening blocker, considering acid guarantees are critical to HBase. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-11013) Clone Snapshots on Secure Cluster Should provide option to apply Retained User Permissions
[
https://issues.apache.org/jira/browse/HBASE-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000754#comment-16000754
]
Ted Yu commented on HBASE-11013:
Can you outline how you test the improvement ?
Thanks
> Clone Snapshots on Secure Cluster Should provide option to apply Retained
> User Permissions
> --
>
> Key: HBASE-11013
> URL: https://issues.apache.org/jira/browse/HBASE-11013
> Project: HBase
> Issue Type: Improvement
> Components: snapshots
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Attachments: HBASE-11013.v1.patch
>
>
> Currently,
> {code}
> sudo su - test_user
> create 't1', 'f1'
> sudo su - hbase
> snapshot 't1', 'snap_one'
> clone_snapshot 'snap_one', 't2'
> {code}
> In this scenario the user - test_user would not have permissions for the
> clone table t2.
> We need to add improvement feature such that the permissions of the original
> table are recorded in snapshot metadata and an option is provided for
> applying them to the new table as part of the clone process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17887) TestAcidGuarantees fails frequently
[
https://issues.apache.org/jira/browse/HBASE-17887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000743#comment-16000743
]
Hadoop QA commented on HBASE-17887:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 52s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 5s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 111m 37s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 153m 39s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestStore |
| | hadoop.hbase.TestAcidGuarantees |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12866876/HBASE-17887.ut.patch |
| JIRA Issue | HBASE-17887 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 51560ebb92f2 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 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 / 0d0ccc3 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| whitespace |
https://builds.apache.org/job/PreCommit-HBASE-Build/6722/artifact/patchprocess/whitespace-eol.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6722/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/6722/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6722/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6722/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This
[jira] [Updated] (HBASE-16432) Revisit the asynchronous ipc implementation
[ https://issues.apache.org/jira/browse/HBASE-16432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-16432: --- Fix Version/s: (was: 1.4.0) > Revisit the asynchronous ipc implementation > --- > > Key: HBASE-16432 > URL: https://issues.apache.org/jira/browse/HBASE-16432 > Project: HBase > Issue Type: Umbrella > Components: rpc >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > > Seems the current approach of implementing AsyncTable is in trouble as we > expose some netty classes in our public interfaces. > I agree that we should not do this. The AsyncTable should be implemented > using the asynchronous protobuf stub, and we could use CompletableFuture or > Deferred instead of netty's Future. I think the problem of netty's future is > that it is tighten with netty's executor. This makes it impossible to use > without netty. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16432) Revisit the asynchronous ipc implementation
[ https://issues.apache.org/jira/browse/HBASE-16432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-16432: --- Fix Version/s: 1.4.0 > Revisit the asynchronous ipc implementation > --- > > Key: HBASE-16432 > URL: https://issues.apache.org/jira/browse/HBASE-16432 > Project: HBase > Issue Type: Umbrella > Components: rpc >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.4.0 > > > Seems the current approach of implementing AsyncTable is in trouble as we > expose some netty classes in our public interfaces. > I agree that we should not do this. The AsyncTable should be implemented > using the asynchronous protobuf stub, and we could use CompletableFuture or > Deferred instead of netty's Future. I think the problem of netty's future is > that it is tighten with netty's executor. This makes it impossible to use > without netty. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-11013) Clone Snapshots on Secure Cluster Should provide option to apply Retained User Permissions
[
https://issues.apache.org/jira/browse/HBASE-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-11013:
-
Status: Patch Available (was: Open)
> Clone Snapshots on Secure Cluster Should provide option to apply Retained
> User Permissions
> --
>
> Key: HBASE-11013
> URL: https://issues.apache.org/jira/browse/HBASE-11013
> Project: HBase
> Issue Type: Improvement
> Components: snapshots
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Attachments: HBASE-11013.v1.patch
>
>
> Currently,
> {code}
> sudo su - test_user
> create 't1', 'f1'
> sudo su - hbase
> snapshot 't1', 'snap_one'
> clone_snapshot 'snap_one', 't2'
> {code}
> In this scenario the user - test_user would not have permissions for the
> clone table t2.
> We need to add improvement feature such that the permissions of the original
> table are recorded in snapshot metadata and an option is provided for
> applying them to the new table as part of the clone process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-11013) Clone Snapshots on Secure Cluster Should provide option to apply Retained User Permissions
[
https://issues.apache.org/jira/browse/HBASE-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000717#comment-16000717
]
Zheng Hu commented on HBASE-11013:
--
In our clusters , there are thousands of table which need to migrate with acl ,
so I try to fix the issue. I uploaded a initial version patch and feedback
are welcome. Thanks.
> Clone Snapshots on Secure Cluster Should provide option to apply Retained
> User Permissions
> --
>
> Key: HBASE-11013
> URL: https://issues.apache.org/jira/browse/HBASE-11013
> Project: HBase
> Issue Type: Improvement
> Components: snapshots
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Attachments: HBASE-11013.v1.patch
>
>
> Currently,
> {code}
> sudo su - test_user
> create 't1', 'f1'
> sudo su - hbase
> snapshot 't1', 'snap_one'
> clone_snapshot 'snap_one', 't2'
> {code}
> In this scenario the user - test_user would not have permissions for the
> clone table t2.
> We need to add improvement feature such that the permissions of the original
> table are recorded in snapshot metadata and an option is provided for
> applying them to the new table as part of the clone process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
