umamaheswararao commented on a change in pull request #1988: URL: https://github.com/apache/hadoop/pull/1988#discussion_r419176899
########## File path: hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFsOverloadScheme.java ########## @@ -0,0 +1,175 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.hadoop.fs.viewfs; + +import java.io.IOException; +import java.lang.reflect.Constructor; +import java.lang.reflect.InvocationTargetException; +import java.net.URI; +import java.net.URISyntaxException; + +import org.apache.hadoop.classification.InterfaceAudience; +import org.apache.hadoop.classification.InterfaceStability; +import org.apache.hadoop.conf.Configuration; +import org.apache.hadoop.fs.FileSystem; +import org.apache.hadoop.fs.FsConstants; +import org.apache.hadoop.fs.UnsupportedFileSystemException; + +/****************************************************************************** + * This class is extended from the ViewFileSystem for the overloaded scheme + * file system. This object is the way end-user code interacts with a multiple + * mounted file systems transparently. Overloaded scheme based uri can be + * continued to use as end user interactive uri and mount links can be + * configured to any Hadoop compatible file system. This class maintains all + * the target file system instances and delegates the calls to respective + * target file system based on mount link mapping. Mount link configuration + * format and behavior is same as ViewFileSystem. + *****************************************************************************/ [email protected]({ "MapReduce", "HBase", "Hive" }) [email protected] +public class ViewFsOverloadScheme extends ViewFileSystem { + + public ViewFsOverloadScheme() throws IOException { + super(); + } + + private FsCreator fsCreator; + private String myScheme; + + @Override + public String getScheme() { + return myScheme; + } + + @Override + public void initialize(final URI theUri, final Configuration conf) + throws IOException { + superFSInit(theUri, conf); + setConf(conf); + config = conf; + myScheme = config.get(FsConstants.VIEWFS_OVERLOAD_SCHEME_KEY); + fsCreator = new FsCreator() { + + /** + * This method is overridden because in ViewFsOverloadScheme if + * overloaded scheme matches with mounted target fs scheme, file system + * should be created without going into fs.<scheme>.impl based + * resolution. Otherwise it will end up into loop as target will be + * resolved again to ViewFsOverloadScheme as fs.<scheme>.impl points to + * ViewFsOverloadScheme. So, below method will initialize the + * fs.viewfs.overload.scheme.target.<scheme>.impl. Other schemes can + * follow fs.newInstance + */ + @Override + public FileSystem createFs(URI uri, Configuration conf) + throws IOException { + if (uri.getScheme().equals(myScheme)) { Review comment: For other schemes which are not matching will be able to get it resolved by FileSystem itself right? When target uri is scheme is same as OverloadScheme uri sheme, then only we need to bypass to avoid looping. Other cases, FileSystem#get or FileSystem#newInstance will get the right instance. Am I missing? Since your exposed uri scheme occupied with OverloadScheme impl, we need that additional config to get actual impl. This was the idea of that configuration. >Currently, the override only works for one scheme. User is going to use one scheme from out side right per OverloadScheme instance right? Because your OverloadScheme init will take one uri to initialize, That will be user initialized uri. Rest all will go as mapping uris. example: inited uri is hdfs://xyz:9000 mapping target uris are /target1 -> hdfs://target1:9000, /target2 -> hdfs://target2:9000, /target3 -> s3a://bucket1/target3 Here when getting target fs: we would check if scheme matches with inited. Here hdfs was inited. So, for hdfs scheme, FileSystem#get resolution will always to OverloadSchem impl. To get actual impl we use the FS_VIEWFS_OVERLOAD_SCHEME_TARGET_FS_IMPL_PATTERN_KEY to initialize target fs. Other impls should be able to resolved by FileSystem#get. Is your use case is for configuring Overload scheme for all fs.<scheme>.impl in same client process? example in same client process, you would configure, fs.hdfs.impl=ViewFSOverloadScheme and fs.s3a.impl=ViewFSOverloadScheme ? Before changing it would be good for me to understand your use case here. -Thanks ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
