[
https://issues.apache.org/jira/browse/DRILL-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942097#comment-15942097
]
ASF GitHub Bot commented on DRILL-5365:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/796#discussion_r108049374
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/DrillFileSystem.java
---
@@ -89,22 +89,36 @@ public DrillFileSystem(Configuration fsConf) throws
IOException {
}
public DrillFileSystem(Configuration fsConf, OperatorStats
operatorStats) throws IOException {
- this.underlyingFs = FileSystem.get(fsConf);
+ this(fsConf, URI.create(fsConf.getRaw(FS_DEFAULT_NAME_KEY)),
operatorStats);
+ }
+
+ public DrillFileSystem(Configuration fsConf, URI Uri, OperatorStats
operatorStats) throws IOException {
+ this.underlyingFs = FileSystem.get(Uri, fsConf);
+ logger.trace("Configuration for the DrillFileSystem " +
fsConf.getRaw(FS_DEFAULT_NAME_KEY) +
+ ", underlyingFs: " + this.underlyingFs.getUri());
this.codecFactory = new CompressionCodecFactory(fsConf);
this.operatorStats = operatorStats;
+ setConf(fsConf);
--- End diff --
I think this whole code block needs more thought. DrillFileSystem derives
from the Hadoop `FileSystem` class, but we never invoke the `FileSystem`
constructor. Why? Without proper init, can we guarantee that the methods
defined in the base class actually work?
On the other hand, it seems we've reimplemented all base class methods,
basically masking the base class implementation. If that is true, why set the
config on the base class?
> FileNotFoundException when reading a parquet file
> -------------------------------------------------
>
> Key: DRILL-5365
> URL: https://issues.apache.org/jira/browse/DRILL-5365
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
> Affects Versions: 1.10.0
> Reporter: Chun Chang
> Assignee: Chunhui Shi
>
> The parquet file is generated through the following CTAS.
> To reproduce the issue: 1) two or more nodes cluster; 2) enable
> impersonation; 3) set "fs.default.name": "file:///" in hive storage plugin;
> 4) restart drillbits; 5) as a regular user, on node A, drop the table/file;
> 6) ctas from a large enough hive table as source to recreate the table/file;
> 7) query the table from node A should work; 8) query from node B as same user
> should reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
