-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HADOOP-18807. Close child file systems in ViewFileSystem when cache is disabled. #5847
Conversation
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zhangshuyan0 Thanks for your works. HADOOP-15565 try to fix this issue, does it not solve or involve new one?
if (!enableInnerCache) { | ||
for (InodeTree.MountPoint<FileSystem> mountPoint : | ||
fsState.getMountPoints()) { | ||
FileSystem targetFs = mountPoint.target.getTargetFileSystemForClose(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about to invoke getTargetFileSystem directly?
@@ -413,6 +413,11 @@ public T getTargetFileSystem() throws IOException { | |||
} | |||
return targetFileSystem; | |||
} | |||
|
|||
T getTargetFileSystemForClose() throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what difference between this method and getTargetFileSystem
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some target FileSystem may not have be initialized. getTargetFileSystem
initializes all target FileSystems (line1039 below). It's costly and unnecessary when we just try to close them.
Lines 1036 to 1039 in c44823d
public FileSystem[] getChildFileSystems() { | |
List<InodeTree.MountPoint<FileSystem>> mountPoints = | |
fsState.getMountPoints(); | |
Map<String, FileSystem> fsMap = initializeMountedFileSystems(mountPoints); |
@Hexiaoqiao Thanks for your review. HADOOP-15565 close child filesystems based on the inner cache of ViewFileSystem. If we disable it , namely set |
Make sense to me. +1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
core design looks good; some questions about production code, and changes suggested for the test case
...p-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java
Show resolved
Hide resolved
if (child != null) { | ||
String disableCacheName = String.format("fs.%s.impl.disable.cache", | ||
child.getUri().getScheme()); | ||
if (config.getBoolean(disableCacheName, false)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we check the child config rather than the viewfs one? would they ever be different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Child file system always use their parent's config. We can take a look at line 346 and line 350 of the code below:
Lines 335 to 361 in c44823d
protected Function<URI, FileSystem> initAndGetTargetFs() { | |
return new Function<URI, FileSystem>() { | |
@Override | |
public FileSystem apply(final URI uri) { | |
FileSystem fs; | |
try { | |
fs = ugi.doAs(new PrivilegedExceptionAction<FileSystem>() { | |
@Override | |
public FileSystem run() throws IOException { | |
if (enableInnerCache) { | |
synchronized (cache) { | |
return cache.get(uri, config); | |
} | |
} else { | |
return fsGetter().get(uri, config); | |
} | |
} | |
}); | |
return new ChRootedFileSystem(fs, uri); | |
} catch (IOException | InterruptedException ex) { | |
LOG.error("Could not initialize the underlying FileSystem " | |
+ "object. Exception: " + ex.toString()); | |
} | |
return null; | |
} | |
}; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@steveloughran means that we should only check viewfs config, rather than every child config here. As you mentioned code segment, it also shows that check viewfs only is enough IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
works for me
*/ | ||
package org.apache.hadoop.fs.viewfs; | ||
|
||
import org.apache.hadoop.conf.Configuration; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
check import ordering
import static org.junit.Assert.assertTrue; | ||
import static org.junit.Assert.fail; | ||
|
||
public class TestViewFileSystemClose { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extend AbstractHadoopTestBase for timeouts, thread naming,...
FileSystem[] children = viewFs.getChildFileSystems(); | ||
viewFs.close(); | ||
FileSystem.closeAll(); | ||
for (FileSystem fs : children) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use LambdaTestUtils.intercept() here
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
package org.apache.hadoop.fs.viewfs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this test uses file:// as the childen fs then it could be added in hadoop common, which is where viewfs is implemented. Doing that means that yetus will run the test on every change to hadoop-common, which is needed to stop regressions in viewfs only being found later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I don't fully understand what you mean. Do you suggest moving this test file to hadoop-common?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, and to use the localfs. yetus doesnt run the hadoop-hdfs tests when a patch just goes near hadoop-common, so the test needs to get there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the cache is disabled, LocalFileSystem#close()
didn't do anything special. That is to say, when the child filesystem is a LocalFileSystem
, whether it is closed or not has little effect. So I think using DistributedFileSystem
in this UT is more appropriate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, and to use the localfs. yetus doesnt run the hadoop-hdfs tests when a patch just goes near hadoop-common, so the test needs to get there.
Hi @steveloughran this change can trigger hadoop-hdfs unit test, but it could not ensure to be launched later actually. I am also concerned it could not cover this case if use local FS only here as @zhangshuyan0 mentioned above 'LocalFileSystem#close() didn't do anything special'. Any suggestions? Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, ok.
💔 -1 overall
This message was automatically generated. |
@steveloughran Thanks for your review and suggestions, which are very valuable. I have updated this PR based on your comment. Would you mind taking a look again? |
💔 -1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed
@@ -17,26 +17,26 @@ | |||
*/ | |||
package org.apache.hadoop.fs.viewfs; | |||
|
|||
import static org.apache.hadoop.test.LambdaTestUtils.intercept; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you put the static imports right down at the bottom, just above the class declaration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
String disableCacheName = String.format("fs.%s.impl.disable.cache", | ||
child.getUri().getScheme()); | ||
if (config.getBoolean(disableCacheName, false)) { | ||
child.close(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do failures need to be handled here? if so: what?
any fs set to delete files on close may raise exceptions here from permissions...should they be ignored, fail fast (as this pr does) or should we try best effort to close the others.
The simple patch here is better than today, so i'm not too worried -and that delete on close stuff isn't something to use in production
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your advice. I will catch IOException here just like ViewFileSystem.InnerCache#closeAll
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 from me.
@Hexiaoqiao anything to add?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. +1.
@steveloughran Please feel free to check in. Thanks.
merged to trunk. @zhangshuyan0 can you do a pr for this against branch-3.3 and once it gets past yetus, I will merge that too. thanks |
…s disabled. (apache#5847) Contributed by Shuyan Zhang
…s disabled. (apache#5847) Contributed by Shuyan Zhang
@steveloughran Done. |
got it: #5865 |
…s disabled. (#5847) Contributed by Shuyan Zhang
…s disabled. (apache#5847) Contributed by Shuyan Zhang
Description of PR
When the cache is configured to disabled (namely,
fs.viewfs.enable.inner.cache=false
andfs.*.impl.disable.cache=true
), even ifFileSystem.close()
is called, the client cannot truly close the child file systems in a ViewFileSystem. This caused our long-running clients to constantly produce resource leaks.How was this patch tested?
Add a new unit test.