Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 4 Dec 2017 17:09:01 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.13122618.1512404886000.379936.1512407341008@Atlassian.JIRA>
In-Reply-To: <JIRA.13122618.1512404886000@Atlassian.JIRA>
References: <JIRA.13122618.1512404886000@Atlassian.JIRA> <JIRA.13122618.1512404886424@jira-lw-us.apache.org>
Subject: [jira] [Commented] (ACCUMULO-4751) Some WALs don't replicate due to
 lacking a createdTime entry
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 04 Dec 2017 17:09:10 -0000


    [ https://issues.apache.org/jira/browse/ACCUMULO-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16277096#comment-16277096 ] 

Josh Elser commented on ACCUMULO-4751:
--------------------------------------

I would say #2 at first glance, but I am more worried about how we missed the createdTime situation.

Ideally, even in the face of TServer crashes, the TServer would set the correct "metadata" on each Status record. Do you have any hunch as to how this record exists without the createdTime attribute set?

It would be nice to confirm that we don't have some other kind of bug lingering in which we're just not writing the record correctly. I wouldn't be surprised if we would actually need some kind of solution (like #2) to guard against some kind of unlikely situation (e.g. tserver failure) in addition another bug. In other words, the catch-all to prevent the system from "wedging" on these WALs would be appreciated.

> Some WALs don't replicate due to lacking a createdTime entry
> ------------------------------------------------------------
>
>                 Key: ACCUMULO-4751
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4751
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.7.3, 1.8.1
>            Reporter: Adam J Shook
>            Assignee: Adam J Shook
>
> From what I can tell, the below error is thrown when no data for a particular table is written to a WAL, but the file is closed.  This would be because the {{Status}} entry from the {{StatusUtil}} for {{fileClosed}} is pre-built and therefore does not have a {{createdTime}}.  This prevents a WAL from being replicated until a {{createdTime}} entry is added manually.
> From the Accumulo master:
> {code}
> Status record ([begin: 0 end: 0 infiniteEnd: true closed: true]) for hdfs://namenode:9000/accumulo/wal/tserver.example.com+31732/f922df9c-3ffc-49ee-8d0c-261c7a05fea2 in table 7l was written to metadata table which lacked createdTime
> {code}
> There are two solutions I have in mind:
> 1. Update the {{StatusUtil}} such that every returned {{Status}} object sets the {{createdTime}} to {{System.currentTimeMillis}} if not explicitly given.
> 2. Update the Accumulo Master to set the {{createdTime}} to the WAL's modification time in HDFS if the WAL is closed but there is no {{createdTime}}.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)