[
https://issues.apache.org/jira/browse/HADOOP-14132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890205#comment-15890205
]
Jason Lowe commented on HADOOP-14132:
-------------------------------------
Ah, I see. Personally I'd rather not support 3 ways to do it, and changing
ours over to the new scheme provides examples (and implicit documentation) on
how others should do it.
That being said, it _is_ more work to convert them over. If we can get a
lightweight one working at all I'm for it even if we don't use it ourselves,
but I think there are advantages to moving our legacy filesystems over to the
new approach.
> Filesystem discovery to stop loading implementation classes
> -----------------------------------------------------------
>
> Key: HADOOP-14132
> URL: https://issues.apache.org/jira/browse/HADOOP-14132
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs, fs/adl, fs/azure, fs/oss, fs/s3, fs/swift
> Affects Versions: 2.7.3
> Reporter: Steve Loughran
> Assignee: Steve Loughran
>
> Integration testing of Hadoop with the HADOOP-14040 has shown up that the
> move to a shaded AWS JAR is slowing all hadoop client code down.
> I believe this is due to how we use service discovery to identify FS
> implementations: the implementation classes themselves are instantiated.
> This has known problems today with classloading, but clearly impacts
> performance too, especially with complex transitive dependencies unique to
> the loaded class.
> Proposed: have lightweight service declaration classes which implement an
> interface declaring
> # schema
> # classname of FileSystem impl
> # classname of AbstractFS impl
> # homepage (for third party code, support, etc)
> These are what we register and scan in the FS to look for services.
> This will leave the question about what to do for existing filesystems? I
> think we'll need to retain the old code for external ones, while moving the
> hadoop modules to the new ones
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
