Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 672BFDC1B for ; Wed, 22 May 2013 18:04:21 +0000 (UTC) Received: (qmail 22016 invoked by uid 500); 22 May 2013 18:04:21 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 21805 invoked by uid 500); 22 May 2013 18:04:21 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 21775 invoked by uid 99); 22 May 2013 18:04:20 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 May 2013 18:04:20 +0000 Received: from localhost (HELO mail-la0-f45.google.com) (127.0.0.1) (smtp-auth username vines, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 May 2013 18:04:19 +0000 Received: by mail-la0-f45.google.com with SMTP id ec20so2321921lab.18 for ; Wed, 22 May 2013 11:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=c/Lg1P/0DGjlTJiKzUrfeXzVmsEYqBYPSRSxbuNd830=; b=WVn65PPvk7BUyQBlbCTtvbVuZq+n/c400NDVK62KBPMW2XnPFAJk4KU2g6BR+u6m3U M66hiFdNbqaDGtrnNO4CzUOAPbhig4AQL5FpFe/5sUNq/Xo/1QOXsezIEDacUeOR4LLC g+Qa7lBuSDreLbbIK0Oe1UhPZndSRjq7Nm0e82GU3F+zvIgqSQKlQjoO0Mqsuub8nhJF M6x6YWkx2oFjDi4He9gq/amWoMu+7RA3pAPmRmEI/m5rKhEvL9O2LC2O5tJs/rMxDoDL FnPh1AipiYEp6tdX3/prTRkuokzdpa+U3Bv5I0U5hXuwhwV4Odjw9kO8j9MWEMRCicF2 DnLw== X-Received: by 10.112.154.170 with SMTP id vp10mr4578525lbb.10.1369245857965; Wed, 22 May 2013 11:04:17 -0700 (PDT) MIME-Version: 1.0 Reply-To: vines@apache.org Received: by 10.114.29.98 with HTTP; Wed, 22 May 2013 11:03:37 -0700 (PDT) In-Reply-To: References: From: John Vines Date: Wed, 22 May 2013 14:03:37 -0400 Message-ID: Subject: Re: MapR compatability To: Eric Newton Cc: Accumulo Dev List , kbotzum@maprtech.com, jfiori@maprtech.com Content-Type: multipart/alternative; boundary=089e01161a44f96fe004dd52641a --089e01161a44f96fe004dd52641a Content-Type: text/plain; charset=ISO-8859-1 I'm just operating in the sandbox VM that MapR put out, not a cluster. I was more concerned about general log writing/recovery. I'm wondering if MapR folks could help with this test. On Wed, May 22, 2013 at 1:40 PM, Eric Newton wrote: > Can you verify that it works well in the presence of the agitator? That > bit of code is supposed to fence off a tablet server from its own logs > after the master determines that it is supposed to be dead. > > -Eric > > > > On Wed, May 22, 2013 at 1:27 PM, John Vines wrote: > >> And it works like a charm. Thanks Eric >> >> >> On Tue, May 21, 2013 at 7:01 PM, John Vines wrote: >> >> > Sigh, I guess I could do that. I was rushing out the door, but I'll try >> > that. >> > >> > Sent from my phone, please pardon the typos and brevity. >> > Or you could configure the MapR log closer. >> > >> > >> > >> > On Tue, May 21, 2013 at 6:36 PM, John Vines wrote: >> > >> > > So I finally got around to testing MapR (well, finally got it >> running). >> > > Gave RC4 a test run and, after seeing the stack trace, not surprised >> it >> > > broke in HadoopLogCloser.close(). IllegalStateException gest thrown >> from >> > > line 54 due to the filesystem being of type >> com.mapr.fs.MapRFileSystem. >> > At >> > > this point, I think this should be considered an acceptable break and >> > > something we shoudl try to resolve first thing for 1.5.1. Thoughts? >> > > >> > >> > > --089e01161a44f96fe004dd52641a--