Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1735452030.1226608964210.JavaMail.jira@brutus>
Date: Thu, 13 Nov 2008 12:42:44 -0800 (PST)
From: "Hong Tang (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-4655) FileSystem.CACHE should be
 ref-counted
In-Reply-To: <1633844090.1226608604134.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647389#action_12647389 ] 

Hong Tang commented on HADOOP-4655:
-----------------------------------

The following code will either result in resource leakage or invalid FileSystem object:

Path path;
 ...
FileSystem fs1 = path.getFileSystem(conf);
...
FileSystem fs2 = path.getFileSystem(conf);
// fs1 should be the same as fs2.
...

fs1.close();
...
FileSystem fs3 = path.getFileSystem(conf);
// fs3 would be a newly created FileSystem object (instead of reusing fs1).

Even worse, if the actual FileSystem implemnetation's close() actually invalidates the object (such as DistributedFileSystem), then fs2 would no longer usable after fs1.close().

This is probably related to HADOOP-319.


> FileSystem.CACHE should be ref-counted
> --------------------------------------
>
>                 Key: HADOOP-4655
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4655
>             Project: Hadoop Core
>          Issue Type: Bug
>            Reporter: Hong Tang
>
> FileSystem.CACHE is not ref-counted, and could lead to resource leakage.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.