hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14680) Two configs for snapshot timeout and better defaults
Date Sat, 24 Oct 2015 17:26:27 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972755#comment-14972755

Hadoop QA commented on HBASE-14680:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  against master branch at commit 418c4422f7fc99ce58bd10c20090f34211da3b13.
  ATTACHMENT ID: 12768519

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:green}+1 hadoop versions{color}. The patch compiles with all supported hadoop versions
(2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.6.1 2.7.0 2.7.1)

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:green}+1 protoc{color}.  The applied patch does not increase the total number of
protoc compiler warnings.

    {color:green}+1 javadoc{color}.  The javadoc tool did not generate any warning messages.

    {color:green}+1 checkstyle{color}.  The applied patch does not increase the total number
of checkstyle errors

    {color:green}+1 findbugs{color}.  The patch does not introduce any  new Findbugs (version
2.0.3) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number
of release audit warnings.

    {color:green}+1 lineLengths{color}.  The patch does not introduce lines longer than 100

  {color:green}+1 site{color}.  The mvn post-site goal succeeds with this patch.

     {color:red}-1 core tests{color}.  The patch failed these unit tests:

Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/16212//testReport/
Release Findbugs (version 2.0.3) 	warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/16212//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: https://builds.apache.org/job/PreCommit-HBASE-Build/16212//artifact/patchprocess/checkstyle-aggregate.html

  Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/16212//console

This message is automatically generated.

> Two configs for snapshot timeout and better defaults
> ----------------------------------------------------
>                 Key: HBASE-14680
>                 URL: https://issues.apache.org/jira/browse/HBASE-14680
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>             Fix For: 2.0.0, 1.3.0, 1.2.1, 1.0.3, 1.1.3, 0.98.16
>         Attachments: HBASE-14680.patch, HBASE-14680_v1.patch, HBASE-14680_v2.patch
> One of the clusters timed out taking a snapshot for a disabled table. The table is big
enough, and the master operation takes more than 1 min to complete. However while trying to
increase the timeout, we noticed that there are two parameters with very similar names configuring
different things: 
> {{hbase.snapshot.master.timeout.millis}} is defined in SnapshotDescriptionUtils and is
send to client side and used in disabled table snapshot. 
> {{hbase.snapshot.master.timeoutMillis}} is defined in SnapshotManager and used as the
timeout for the procedure execution. 
> So, there are a couple of improvements that we can do: 
>  - 1 min is too low for big tables. We need to set this to 5 min or 10 min by default.
Even a 6T table which is medium sized fails. 
>  - Unify the two timeouts into one. Decide on either of them, and deprecate the other.
Use the biggest one for BC. 
>  - Add the timeout to hbase-default.xml. 
>  - Why do we even have a timeout for disabled table snapshots? The master is doing the
work so we should not timeout in any case. 

This message was sent by Atlassian JIRA

View raw message