Re: Temporarily disabled the timeout setting for flakey tests jenkins job

[Stack]

Duo:

A bad nightly build ruined our dashboard. A bad run produced many tests for
the flakies list. The flakies list then timed out because too many tests to
run.  Appy cleaned it up, mostly. It will take a few hours for the failures
to clear out (it seems to be coming along nicely).

I should have dumped note in here on dev that we were working on it so you
didn't have to waste your time.

Thanks,
S



On Tue, Feb 27, 2018 at 6:27 PM, 张铎(Duo Zhang) 
wrote:

> Not sure why it happens but the build timeout is set to the default value
> which is 50 minutes instead of depending on the previous build time.
> Disable the timeout setting to see if it helps.
>

[jira] [Created] (HBASE-20104) Fix infinite loop of RIT when creating table on a rsgroup that has no online servers

[Xiaolin Ha (JIRA)]

Xiaolin Ha created HBASE-20104:
--

 Summary: Fix infinite loop of RIT when creating table on a rsgroup 
that has no online servers
 Key: HBASE-20104
 URL: https://issues.apache.org/jira/browse/HBASE-20104
 Project: HBase
  Issue Type: Bug
  Components: rsgroup
Affects Versions: 2.0.0-beta-2
Reporter: Xiaolin Ha
Assignee: Xiaolin Ha


This error has been reported in 
https://builds.apache.org/job/PreCommit-HBASE-Build/11635/testReport/org.apache.hadoop.hbase.rsgroup/TestRSGroups/org_apache_hadoop_hbase_rsgroup_TestRSGroups/

Cases that creating tables on a rsgroup which has been stopped or 
decommissioned all region servers can reproduce this error. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] The second HBase 1.4.2 release candidate (RC1) is available

[Yu Li]

+1

Checked sums and signatures: ok
Built from source: ok (7u79)
RAT check: ok (7u79)
Compatibility check: ok (7u79)
Unit tests pass: ok (7u79)
Loaded 1M rows with LTT: ok (8u101), all keys verified, latency and logs
looks good
Shell commands: ok (8u101), ran DDL/flush/compact/split commands,
everything looks good


Best Regards,
Yu

On 27 February 2018 at 20:31, ashish singhi 
wrote:

> +1
>
> Downloaded the binary and checked the followings,
>
> - Checked LICENSE and NOTICE files, looks ok
> - Apache RAT check, looks good
>
> Verified the following in a non-secure setup,
>
> - Exercised basic shell commands
> - Ran LTT with 1M row, checked read and write operations
> - Poked around webUI
> - Started Rest server and executed some commands
> - Checked logs
>
> Regards,
> Ashish
>
> -Original Message-
> From: Andrew Purtell [mailto:apurt...@apache.org]
> Sent: Friday, February 23, 2018 5:26 AM
> To: dev 
> Subject: [VOTE] The second HBase 1.4.2 release candidate (RC1) is available
>
> The second HBase 1.4.2 release candidate (RC1) is available for download
> at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC1/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1196/ .
>
> The git tag corresponding to the candidate is '1.4.2RC1' (b4ec89059c).
> Note this is different from branch-1.4 by one commit because we had an
> intervening commit between tag and push (08b9939974, HBASE-20016) while I
> was running tests. The only difference is the CHANGES.txt update for
> 1.4.2RC1 is placed ahead of the commit for HBASE-20016, but does not
> mention it, which is fine, because 1.4.2RC1 does not contain HBASE-20016.
>
> A detailed source and binary compatibility report for this release is
> available for your review at https://dist.apache.org/repos/
> dist/dev/hbase/hbase-1.4.2RC1/compat-check-report.html
> .
>
> A list of the 22 issues resolved in this release can be found at
> https://s.apache.org/aGcb .
>
> Please try out the candidate and vote +1/0/-1.
>
> This vote will be open for at least 72 hours. Unless objection I will try
> to close it Thursday February 28, 2018 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks:
>
>- RAT check passes (7u80)
>- Unit test suite passes (8u131)
>- LTT load 1M rows with 100% verification and 20% updates (8u131)
>- PE sequentialWrite, sequentialRead, randomWrite, randomRead,
>scanRange100 (8u131)
>- ITBLL Loop 1 100M rows (8u131)
>
>
>
> --
> Best regards,
> Andrew
>

Temporarily disabled the timeout setting for flakey tests jenkins job

[Duo Zhang]

Not sure why it happens but the build timeout is set to the default value
which is 50 minutes instead of depending on the previous build time.
Disable the timeout setting to see if it helps.

[jira] [Resolved] (HBASE-19989) READY_TO_MERGE and READY_TO_SPLIT do not update region state correctly

[Andrew Purtell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell resolved HBASE-19989.

Resolution: Fixed

Pushed addendum to branch-1.3, branch-1.4, and branch-1

> READY_TO_MERGE and READY_TO_SPLIT do not update region state correctly
> --
>
> Key: HBASE-19989
> URL: https://issues.apache.org/jira/browse/HBASE-19989
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.1, 1.4.1
>Reporter: Ben Lau
>Assignee: Ben Lau
>Priority: Major
> Fix For: 1.3.2, 1.5.0, 1.4.3
>
> Attachments: HBASE-19989-ADDENDUM-branch-1.patch, 
> HBASE-19989-branch-1.patch
>
>
> Region state transitions do not work correctly for READY_TO_MERGE/SPLIT.  
> [~thiruvel] and I noticed this is due to break statements being in the wrong 
> place in AssignmentManager.  This allows a race condition for example in 
> which one of the regions being merged could be moved concurrently, resulting 
> in the merge transaction failing and then double assignment and/or dataloss.  
> This bug appears to only affect branch-1 (for example 1.3 and 1.4) and not 
> branch-2 as the relevant code in AM has since been rewritten.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20103) [pv2] AssignmentProcedure is too coarse grained

[stack (JIRA)]

stack created HBASE-20103:
-

 Summary: [pv2] AssignmentProcedure is too coarse grained
 Key: HBASE-20103
 URL: https://issues.apache.org/jira/browse/HBASE-20103
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: stack


Comes of work on HBASE-20100 but in particular, in feedback from [~Apache9] 
https://mail.google.com/mail/u/0/#inbox/161d8e41054be406

The AP is too coarse-grained. There is precheck+start, then transform state is 
edit meta setting state to OPENING and then dispatch (rpc)  Finish is edit 
of meta and setting internal state. The edit of meta should be distinct step at 
least.

Would save on duplicated ops -- e.g. re-editing hbase:meta and dispatching 
another RPC -- if we fail going into finishing. [~Apache9] brings up our 
perhaps masking other state change hiccups when steps are so coarse-grained.

Do same for unassignprocedure.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (HBASE-19989) READY_TO_MERGE and READY_TO_SPLIT do not update region state correctly

[Andrew Purtell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell reopened HBASE-19989:


The new tests TestZKLessMergeOnCluster and TestZKLessSplitOnCluster 
consistently fail for me on branch-1.3 and branch-1.4. 

{code}
java.lang.RuntimeException: 
org.apache.hadoop.hbase.exceptions.DeserializationException: Missing pb magic 
PBUF prefix
{code}



> READY_TO_MERGE and READY_TO_SPLIT do not update region state correctly
> --
>
> Key: HBASE-19989
> URL: https://issues.apache.org/jira/browse/HBASE-19989
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.1, 1.4.1
>Reporter: Ben Lau
>Assignee: Ben Lau
>Priority: Major
> Fix For: 1.3.2, 1.5.0, 1.4.3
>
> Attachments: HBASE-19989-branch-1.patch
>
>
> Region state transitions do not work correctly for READY_TO_MERGE/SPLIT.  
> [~thiruvel] and I noticed this is due to break statements being in the wrong 
> place in AssignmentManager.  This allows a race condition for example in 
> which one of the regions being merged could be moved concurrently, resulting 
> in the merge transaction failing and then double assignment and/or dataloss.  
> This bug appears to only affect branch-1 (for example 1.3 and 1.4) and not 
> branch-2 as the relevant code in AM has since been rewritten.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20102) AssignmentManager#shutdown doesn't shut down scheduled executor

[Andrew Purtell (JIRA)]

Andrew Purtell created HBASE-20102:
--

 Summary: AssignmentManager#shutdown doesn't shut down scheduled 
executor
 Key: HBASE-20102
 URL: https://issues.apache.org/jira/browse/HBASE-20102
 Project: HBase
  Issue Type: Bug
  Components: master, Region Assignment
Affects Versions: 1.4.2
Reporter: Andrew Purtell
Assignee: Andrew Purtell
 Fix For: 1.5.0, 1.4.3






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-20092) Fix TestRegionMetrics#testRegionMetrics

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-20092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack resolved HBASE-20092.
---
Resolution: Fixed

Re-resolving after reverting the revert. I don' t this the problem. Our 
dashboard is just messed up 

> Fix TestRegionMetrics#testRegionMetrics
> ---
>
> Key: HBASE-20092
> URL: https://issues.apache.org/jira/browse/HBASE-20092
> Project: HBase
>  Issue Type: Task
>  Components: test
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-20092.v0.patch
>
>
> {code:java}
> java.lang.AssertionError: expected:<12> but was:<13>
>   at 
> org.apache.hadoop.hbase.TestRegionMetrics.testRegionMetrics(TestRegionMetrics.java:111){code}
> [http://104.198.223.121:8080/job/HBASE-Flaky-Tests/34589/testReport/junit/org.apache.hadoop.hbase/TestRegionMetrics/testRegionMetrics/]
> http://104.198.223.121:8080/job/HBASE-Flaky-Tests/34591/testReport/junit/org.apache.hadoop.hbase/TestRegionMetrics/testRegionMetrics/
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20101) HBase should provide a way to re-validate locality

[Jean-Marc Spaggiari (JIRA)]

Jean-Marc Spaggiari created HBASE-20101:
---

 Summary: HBase should provide a way to re-validate locality
 Key: HBASE-20101
 URL: https://issues.apache.org/jira/browse/HBASE-20101
 Project: HBase
  Issue Type: New Feature
Reporter: Jean-Marc Spaggiari


HDFS blocks can move for many reasons. HDFS balancing, lost of a disk, of a 
node, etc. However, today, locality seems to be calculated when the files are 
opened for the first time. Even disabling and re-enabling the regions doesn't 
trigger a re-calculation of the locality. 

We should provide a way to let the user ask for this number to be re-calculated.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20100) TestEnableTableProcedure flakey

[stack (JIRA)]

stack created HBASE-20100:
-

 Summary: TestEnableTableProcedure flakey
 Key: HBASE-20100
 URL: https://issues.apache.org/jira/browse/HBASE-20100
 Project: HBase
  Issue Type: Sub-task
Reporter: stack


Failed in the nightly in interesting way. 

https://builds.apache.org/job/HBase%20Nightly/job/branch-2/398/

A subprocedure of enable table is assigning regions. The test is doing a kill 
of the procedure store  to ensure we can handle all state transtions even in 
face of failure. In this case, the kill of PE framework came in the finish of 
the assign procedure AFTER we'd updated hbase:meta and the internal AM state 
moving Region from OPENING to OPEN. Rerunning this step on restoration of the 
AMv2 WAL Store results in


{code}
2018-02-27 16:28:02,290 WARN  [PEWorker-1] 
assignment.RegionTransitionProcedure(331): Retryable error trying to 
transition: pid=64, ppid=52, state=RUNNABLE:REGION_TRANSITION_FINISH; 
AssignProcedure table=testRecoveryAndDoubleExecution, 
region=cdc8d2202f4aa4daf381bf1bf2e2fe0c; rit=OPEN, 
location=104080720bc8,38818,1519748808967
org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected [OFFLINE, 
CLOSED, SPLITTING, SPLIT, OPENING, FAILED_OPEN] so could move to OPEN but 
current state=OPEN
{code}





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-19169) Rowcounter job fails against hadoop3 beta1

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu resolved HBASE-19169.

Resolution: Cannot Reproduce

> Rowcounter job fails against hadoop3 beta1
> --
>
> Key: HBASE-19169
> URL: https://issues.apache.org/jira/browse/HBASE-19169
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Priority: Major
>
> I got the following error running rowcounter against hadoop3 beta1 based on 
> commit a9f0c5d4e2c85c1faae1b4b277e3c290c8b81d2a :
> {code}
> 2017-11-03 17:10:59,583 INFO  [main] mapreduce.Job: Task Id : 
> attempt_1509641483571_0006_m_29_1, Status : FAILED
> Error: java.lang.ArrayIndexOutOfBoundsException: 2
>   at 
> org.apache.hadoop.hbase.mapreduce.TableSplit$Version.fromCode(TableSplit.java:77)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableSplit.readFields(TableSplit.java:285)
>   at 
> org.apache.hadoop.io.serializer.WritableSerialization$WritableDeserializer.deserialize(WritableSerialization.java:71)
>   at 
> org.apache.hadoop.io.serializer.WritableSerialization$WritableDeserializer.deserialize(WritableSerialization.java:42)
>   at org.apache.hadoop.mapred.MapTask.getSplitDetails(MapTask.java:372)
>   at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:760)
>   at org.apache.hadoop.mapred.MapTask.run(MapTask.java:341)
>   at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:174)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1962)
>   at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:168)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-19813) clone_snapshot fails with region failing to open when RS group feature is enabled

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu resolved HBASE-19813.

Resolution: Duplicate

Dup of HBASE-17785 

> clone_snapshot fails with region failing to open when RS group feature is 
> enabled
> -
>
> Key: HBASE-19813
> URL: https://issues.apache.org/jira/browse/HBASE-19813
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Priority: Major
>
> The following scenario came from support case.
> In cluster 1, create RS group rsg. Move table to rsg group.
> Take snapshot of the table and copy the snapshot to cluster 2 where there is 
> no group called rsg.
> Cloning snapshot to table new_t4 on cluster 2 fails :
> {code}
> 2018-01-09 11:45:30,468 INFO  [RestoreSnapshot-pool68-t1] 
> regionserver.HRegion: Closed 
> new_t4,,1514454789243.a6173d2955182ac5bde208301681c6af.
> 2018-01-09 11:45:30,468 INFO  [MASTER_TABLE_OPERATIONS-shubh1-1:16000-0] 
> snapshot.CloneSnapshotHandler: Clone snapshot=snap_t3 on table=new_t4 
> completed!
> 2018-01-09 11:45:30,492 INFO  [MASTER_TABLE_OPERATIONS-shubh1-1:16000-0] 
> hbase.MetaTableAccessor: Added 1
> 2018-01-09 11:45:30,492 WARN  [MASTER_TABLE_OPERATIONS-shubh1-1:16000-0] 
> rsgroup.RSGroupBasedLoadBalancer: Group for table new_t4 is null
> 2018-01-09 11:45:30,492 DEBUG [MASTER_TABLE_OPERATIONS-shubh1-1:16000-0] 
> rsgroup.RSGroupBasedLoadBalancer: Group Information found to be null. Some 
> regions might be unassigned.
> 2018-01-09 11:45:30,492 WARN  [MASTER_TABLE_OPERATIONS-shubh1-1:16000-0] 
> master.RegionStates: Failed to open/close a6173d2955182ac5bde208301681c6af on 
> null, set to FAILED_OPEN
> {code}
> Here is related code from RSGroupBasedLoadBalancer:
> {code}
> List candidateList = filterOfflineServers(info, servers);
> for (RegionInfo region : regionList) {
>   currentAssignmentMap.put(region, regions.get(region));
> }
> if(candidateList.size() > 0) {
>   assignments.putAll(this.internalBalancer.retainAssignment(
>   currentAssignmentMap, candidateList));
> {code}
> candidateList is empty for table new_t4, leaving region for the table in 
> FAILED_OPEN state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-18985) Fix the building warning of missing version in hbase-shaded-check-invariants module

[Artem Ervits (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Artem Ervits resolved HBASE-18985.
--
Resolution: Duplicate

Duplicate of https://issues.apache.org/jira/browse/HBASE-20091 [~apurtell] do 
you think we need to apply this to 1.2 and 1.3 branches?

> Fix the building warning of missing version in hbase-shaded-check-invariants 
> module
> ---
>
> Key: HBASE-18985
> URL: https://issues.apache.org/jira/browse/HBASE-18985
> Project: HBase
>  Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Priority: Minor
>  Labels: beginner
> Fix For: 1.3.2, 1.5.0, 1.2.8, 1.4.3
>
>
> {quote}
> 19:20:38 [WARNING] 
> 19:20:38 [WARNING] Some problems were encountered while building the 
> effective model for 
> org.apache.hbase:hbase-shaded-check-invariants:pom:1.2.7-SNAPSHOT
> 19:20:38 [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.mojo:exec-maven-plugin is missing. @ 
> org.apache.hbase:hbase-shaded-check-invariants:[unknown-version], 
> /var/lib/jenkins/workspace/PreCommit-HBASE-BRANCH-1.2/hbase-shaded/hbase-shaded-check-invariants/pom.xml,
>  line 161, column 15
> 19:20:38 [WARNING] 
> 19:20:38 [WARNING] It is highly recommended to fix these problems because 
> they threaten the stability of your build.
> 19:20:38 [WARNING] 
> 19:20:38 [WARNING] For this reason, future Maven versions might no longer 
> support building such malformed projects.
> 19:20:38 [WARNING] 
> {quote}
> This warning doesn't occur on master because it had been fixed by HBASE-18723.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20099) Need to support per procedure killAndToggleBeforeStoreUpdate

[Umesh Agashe (JIRA)]

Umesh Agashe created HBASE-20099:


 Summary: Need to support per procedure 
killAndToggleBeforeStoreUpdate
 Key: HBASE-20099
 URL: https://issues.apache.org/jira/browse/HBASE-20099
 Project: HBase
  Issue Type: Improvement
  Components: proc-v2
Affects Versions: 2.0.0
Reporter: Umesh Agashe
 Fix For: 2.1.0


Currently there is procedure framework wide killAndToggleBeforeStoreUpdate. 
This affects all procedures being executed by procedure framework including 
sub-procedures. Procedure specific toggle can be added as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (HBASE-20069) fix existing findbugs errors in hbase-server

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-20069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack reopened HBASE-20069:
---

Reopened. Reverted to see if this responsible for slow downs/hangs seen up on 
https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests-branch2.0/lastSuccessfulBuild/artifact/dashboard.html

> fix existing findbugs errors in hbase-server
> 
>
> Key: HBASE-20069
> URL: https://issues.apache.org/jira/browse/HBASE-20069
> Project: HBase
>  Issue Type: Sub-task
>  Components: findbugs
>Reporter: Sean Busbey
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-beta-2
>
> Attachments: 
> 0001-HBASE-20069-fix-existing-findbugs-errors-addendum.patch, 
> 0002-HBASE-20069-fix-existing-findbugs-errors-addendum.patch, FindBugs 
> Report.htm, HBASE-20069.branch-2.001.patch, HBASE-20069.branch-2.002.patch, 
> HBASE-20069.branch-2.003.patch, HBASE-20069.branch-2.004.patch
>
>
> now that findbugs is running on precommit we have some cleanup to do.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (HBASE-20092) Fix TestRegionMetrics#testRegionMetrics

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-20092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack reopened HBASE-20092:
---

Reverted. We've started timing out replication tests. Let me see if this 
responsible (yeah, this passed tests and initial run up in flakeys passed but 
...  trying stuff). Reopening while reverted.

> Fix TestRegionMetrics#testRegionMetrics
> ---
>
> Key: HBASE-20092
> URL: https://issues.apache.org/jira/browse/HBASE-20092
> Project: HBase
>  Issue Type: Task
>  Components: test
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-20092.v0.patch
>
>
> {code:java}
> java.lang.AssertionError: expected:<12> but was:<13>
>   at 
> org.apache.hadoop.hbase.TestRegionMetrics.testRegionMetrics(TestRegionMetrics.java:111){code}
> [http://104.198.223.121:8080/job/HBASE-Flaky-Tests/34589/testReport/junit/org.apache.hadoop.hbase/TestRegionMetrics/testRegionMetrics/]
> http://104.198.223.121:8080/job/HBASE-Flaky-Tests/34591/testReport/junit/org.apache.hadoop.hbase/TestRegionMetrics/testRegionMetrics/
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Still Failing: HBase Generate Website

[Apache Jenkins Server]

Build status: Still Failing

The HBase website has not been updated to incorporate HBase commit 
${CURRENT_HBASE_COMMIT}.

See https://builds.apache.org/job/hbase_generate_website/1267/console

[jira] [Created] (HBASE-20098) Fix TestSplitTransactionOnCluster#testMasterRestartWhenSplittingIsPartial for branch-1.2

[Chia-Ping Tsai (JIRA)]

Chia-Ping Tsai created HBASE-20098:
--

 Summary: Fix 
TestSplitTransactionOnCluster#testMasterRestartWhenSplittingIsPartial for 
branch-1.2
 Key: HBASE-20098
 URL: https://issues.apache.org/jira/browse/HBASE-20098
 Project: HBase
  Issue Type: Task
  Components: test
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
 Fix For: 1.2.7


The new master started by 
TestSplitTransactionOnCluster#testMasterRestartWhenSplittingIsPartial will 
enable the CatalogJanitor. Hence, the parent region in SPLIT state will be 
removed by CatalogJanitor since all reference files of the parent region are 
removed by previous compaction.

branch-1.3+ aren't in this trouble since HBASE-13082 and HBASE-14970 make the 
compacted file be archived by a background thread. Before the thread cleans up 
the compacted files, the parent region in SPLIT state won't be removed as there 
are file is referenced by its daughter region.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

RE: [VOTE] The second HBase 1.4.2 release candidate (RC1) is available

[ashish singhi]

+1

Downloaded the binary and checked the followings,

- Checked LICENSE and NOTICE files, looks ok
- Apache RAT check, looks good

Verified the following in a non-secure setup,

- Exercised basic shell commands
- Ran LTT with 1M row, checked read and write operations
- Poked around webUI
- Started Rest server and executed some commands
- Checked logs

Regards,
Ashish

-Original Message-
From: Andrew Purtell [mailto:apurt...@apache.org] 
Sent: Friday, February 23, 2018 5:26 AM
To: dev 
Subject: [VOTE] The second HBase 1.4.2 release candidate (RC1) is available

The second HBase 1.4.2 release candidate (RC1) is available for download at 
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC1/ and Maven 
artifacts are available in the temporary repository 
https://repository.apache.org/content/repositories/orgapachehbase-1196/ .

The git tag corresponding to the candidate is '1.4.2RC1' (b4ec89059c). Note 
this is different from branch-1.4 by one commit because we had an intervening 
commit between tag and push (08b9939974, HBASE-20016) while I was running 
tests. The only difference is the CHANGES.txt update for
1.4.2RC1 is placed ahead of the commit for HBASE-20016, but does not mention 
it, which is fine, because 1.4.2RC1 does not contain HBASE-20016.

A detailed source and binary compatibility report for this release is available 
for your review at 
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC1/compat-check-report.html
.

A list of the 22 issues resolved in this release can be found at 
https://s.apache.org/aGcb .

Please try out the candidate and vote +1/0/-1.

This vote will be open for at least 72 hours. Unless objection I will try to 
close it Thursday February 28, 2018 if we have sufficient votes.

Prior to making this announcement I made the following preflight checks:

   - RAT check passes (7u80)
   - Unit test suite passes (8u131)
   - LTT load 1M rows with 100% verification and 20% updates (8u131)
   - PE sequentialWrite, sequentialRead, randomWrite, randomRead,
   scanRange100 (8u131)
   - ITBLL Loop 1 100M rows (8u131)



--
Best regards,
Andrew