From issues-return-329522-archive-asf-public=cust-asf.ponee.io@hbase.apache.org Fri Jan 12 17:14:07 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id EDCC5180621 for ; Fri, 12 Jan 2018 17:14:06 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id DD32F160C33; Fri, 12 Jan 2018 16:14:06 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2D6DD160C30 for ; Fri, 12 Jan 2018 17:14:06 +0100 (CET) Received: (qmail 35051 invoked by uid 500); 12 Jan 2018 16:14:05 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 35040 invoked by uid 99); 12 Jan 2018 16:14:05 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jan 2018 16:14:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id D1F7A1808D2 for ; Fri, 12 Jan 2018 16:14:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -108.711 X-Spam-Level: X-Spam-Status: No, score=-108.711 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id ZaQqOuLb7wQA for ; Fri, 12 Jan 2018 16:14:04 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 650075F576 for ; Fri, 12 Jan 2018 16:14:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 10902E08C2 for ; Fri, 12 Jan 2018 16:14:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4215C25BDA for ; Fri, 12 Jan 2018 16:14:00 +0000 (UTC) Date: Fri, 12 Jan 2018 16:14:00 +0000 (UTC) From: "stack (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-19533) How to do controlled shutdown in branch-2? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-19533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19533: -------------------------- Priority: Critical (was: Major) > How to do controlled shutdown in branch-2? > ------------------------------------------ > > Key: HBASE-19533 > URL: https://issues.apache.org/jira/browse/HBASE-19533 > Project: HBase > Issue Type: Task > Reporter: stack > Priority: Critical > Fix For: 2.0.0-beta-2 > > > Before HBASE-18946, setting shutdown of a cluster, the Master would exit immediately. RegionServers would run region closes and then try and notify the Master of the close and would spew exceptions that the Master was unreachable. > This is different to how branch-1 used to do it. It used to keep Master up and it would be like the captain of the ship, the last to go down. As of HBASE-18946, this is again the case but there are still open issues. > # Usually Master does all open and close of regions. On cluster shutdown, it is the one time where the Regions run the region close. Currently, the regions report the close to the Master which disregards the message since it did not start the region closes. Should we do different? Try and update state in hbase:meta setting it to CLOSE? We might not be able to write CLOSE for all regions since hbase:meta will be closing too (the RS that is hosting hbase:meta will close it last.... but that may not be enough). > # Should the Master run the cluster shutdown sending out close for all regions? What if cluster of 1M regions? Untenable? Send a message per server? That might be better. > Anyways, this needs attention. Filing issue in meantime. -- This message was sent by Atlassian JIRA (v6.4.14#64029)