Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 11 Sep 2014 00:11:33 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12740649.1410394251000.5151.1410394293743@Atlassian.JIRA>
In-Reply-To: <JIRA.12740649.1410394251000@Atlassian.JIRA>
References: <JIRA.12740649.1410394251000@Atlassian.JIRA>
 <JIRA.12740649.1410394251529@arcas>
Subject: [jira] [Created] (ACCUMULO-3109) MonitorLoggingIT sometimes fails
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Josh Elser created ACCUMULO-3109:
------------------------------------

             Summary: MonitorLoggingIT sometimes fails
                 Key: ACCUMULO-3109
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3109
             Project: Accumulo
          Issue Type: Bug
          Components: test
            Reporter: Josh Elser
            Assignee: Josh Elser
            Priority: Trivial
             Fix For: 1.6.1, 1.7.0


MonitorLoggingIT contains to fail for me on different platforms. It ends up waiting for the log message to show up until the test eventually times out.

The code waits for the Monitor to be up, that it placed its location in ZooKeeper. However, for log-forwarding to be active, any tserver running also has to get the watcher update for the log4j-forwarding node that the monitor updates.

My hunch is that we did the scan, caused the error, and then log4j forwarding was enabled. Should be able to stabilize by waiting before we scan. To definitively know, we'd have to add something to the RPC for tservers to query what their current log-forwarding "state" is (which probably isn't worth the hassle).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)