Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 4 Aug 2014 21:14:13 +0000 (UTC)
From: "Eric Newton (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12730193.1406553841446.10694.1407186853907@arcas>
In-Reply-To: <JIRA.12730193.1406553841446@arcas>
References: <JIRA.12730193.1406553841446@arcas>
Subject: [jira] [Assigned] (ACCUMULO-3024) VFS classloader can randomly fail
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ACCUMULO-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Newton reassigned ACCUMULO-3024:
-------------------------------------

    Assignee: Eric Newton

> VFS classloader can randomly fail
> ---------------------------------
>
>                 Key: ACCUMULO-3024
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3024
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.5.0, 1.5.1, 1.6.0
>            Reporter: Brian Loss
>            Assignee: Eric Newton
>             Fix For: 1.6.1, 1.7.0
>
>
> The fix for ACCUMULO-1321 appears to have broken the VFS classloader.  The problem is that when a UniqueFileReplicator is cleaned up, it deletes the temp directory that is holding all of the files in the classpath.
> The situation we have seen is as follows:
> 1. Configuration includes a general VFS classpath and 2 context VFS classpaths.
> 2. At tserver startup, multiple VFS objects are created.
> 3. Finalize is called on one of them and that deletes the process-specific temp dir (which is shared by all of the objects).
> 4. I attempted to set a table.classpath.context on a table, and got errors from UniqueFileReplicator since it couldn't create a copy of the VFS files since its temp directory had already been cleaned up.


--
This message was sent by Atlassian JIRA
(v6.2#6252)