Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 615D0F35C for ; Sat, 30 Mar 2013 21:37:15 +0000 (UTC) Received: (qmail 50828 invoked by uid 500); 30 Mar 2013 21:37:15 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 50759 invoked by uid 500); 30 Mar 2013 21:37:15 -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 50750 invoked by uid 99); 30 Mar 2013 21:37:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 30 Mar 2013 21:37:15 +0000 Date: Sat, 30 Mar 2013 21:37:15 +0000 (UTC) From: "Lars Hofhansl (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-8229) Replication code logs like crazy if a target table cannot be found. 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-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618164#comment-13618164 ] Lars Hofhansl commented on HBASE-8229: -------------------------------------- If we skip, we can never go back a reapply these edits; I don't think that would be a good idea. Like Jieshan I was thinking we should treat like the peer cluster is not available (at least in terms waiting - we do not have the rechoose the sinks in that case). > Replication code logs like crazy if a target table cannot be found. > ------------------------------------------------------------------- > > Key: HBASE-8229 > URL: https://issues.apache.org/jira/browse/HBASE-8229 > Project: HBase > Issue Type: Bug > Reporter: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > > One of our RS/DN machines ran out of diskspace on the partition to which we write the log files. > It turns out we still had a table in our source cluster with REPLICATION_SCOPE=>1 that did not have a matching table in the remote cluster. > In then logged a long stack trace every 50ms or so, over a few days that filled up our log partition. > Since ReplicationSource cannot make any progress in this case anyway, it should probably sleep a bit before retrying (or at least limit the rate at which it spews out these exceptions to the log). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira