[
https://issues.apache.org/jira/browse/HADOOP-17028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370546#comment-17370546
]
Steve Loughran commented on HADOOP-17028:
-----------------------------------------
bq. Steve, this looks like incompatible change as it replaced the parameter to
a different class...
In a world of @Functional params, it is compatible. But I suspect that you are
right about link-time matching; the JVM probably isn't going to blindly treat
them as equivalent.
bq. One good thing about it that you can remove the deprecated classes as they
have never been used.
not used in hadoop-*. My fear was that they had been picked up/used in google
GCS. I've been building that connector and I don't see it in use.
Given that I'll target it for removal in 3.3.2
bq. You don't seem to care about older versions, but many people do.
I really do. I am the one currently staring at the ABFS Code and a branch-2
build. At the same time, being more isolated (and, let's be ruthless: lower
risk), the object storage code has been able to evolve faster than other bits
of the codebase.
FWIW the main troublespot in backporting cloud storage changes, esp in
hadoop-azure, is actually mockito versions. something which works on mockito 2
is still likely to compile on mockito 1.x but then fail with some "impossible"
stack trace, and I'm left trying to distinguish between "mockito lib version
issues, fix test or cut", "different codepath breaks mockito test" and "test
has actually found a regression". It's a key reason why I don't like
mockito-based testing.
> ViewFS should initialize target filesystems lazily
> --------------------------------------------------
>
> Key: HADOOP-17028
> URL: https://issues.apache.org/jira/browse/HADOOP-17028
> Project: Hadoop Common
> Issue Type: Bug
> Components: client-mounts, fs, viewfs
> Affects Versions: 3.2.1
> Reporter: Uma Maheswara Rao G
> Assignee: Abhishek Das
> Priority: Major
> Labels: pull-request-available
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> Currently viewFS initialize all configured target filesystems when
> viewfs#init itself.
> Some target file system initialization involve creating heavy objects and
> proxy connections. Ex: DistributedFileSystem#initialize will create DFSClient
> object which will create proxy connections to NN etc.
> For example: if ViewFS configured with 10 target fs with hdfs uri and 2
> targets with s3a.
> If one of the client only work with s3a target, But ViewFS will initialize
> all targets irrespective of what clients interested to work with. That means,
> here client will create 10 DFS initializations and 2 s3a initializations. Its
> unnecessary to have DFS initialization here. So, it will be a good idea to
> initialize the target fs only when first time usage call come to particular
> target fs scheme.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
