Skip to content
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.

Sign up for GitHub

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

Make sure ufs to only once load a native shared library #14058

Open
wants to merge 4 commits into
base: master-2.x
Choose a base branch
from
Open

Make sure ufs to only once load a native shared library #14058

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d180809
Alluxio/core: make sure ufs to only once load a native shared library…
jhonxue Sep 13, 2021
5b124f1
Alluxio/core: make sure ufs to only once load a native shared library…
jhonxue Sep 13, 2021
37139ca
Alluxio/core: make sure ufs to only once load a native shared library…
jhonxue Sep 18, 2021
303bd9b
Merge branch 'master' into alluxio_dev_xyt
jhonxue Jan 10, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 29 additions & 8 deletions core/common/src/main/java/alluxio/extensions/ExtensionFactoryRegistry.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,19 +131,18 @@ public List<T> findAll(String path, S conf) {
Preconditions.checkArgument(path != null, "path may not be null");

List<T> factories = new ArrayList<>(mFactories);
List<T> eligibleFactories = select(path, conf, factories);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean the first time findAll invoked, the mFactories should be empty, and this method will run like original logic, later new findAll will not load the extension or lib jar at all? So please show the effect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean the first time findAll invoked, the mFactories should be empty, and this method will run like original logic, later new findAll will not load the extension or lib jar at all? So please show the effect.

Yes, the new 'findAll' will not dynamicly load the ext or lib jar after the first load done. However, we can restart the alluxio master or worker to load the new updated jar.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please highlight add this important limitation to the related issue or the description of this PR. It would be better if you write an approach description shortly to let reviewer know your solution and make it easy to review this PR

if (!eligibleFactories.isEmpty()) {
return eligibleFactories;
}

factories.clear();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't understand why we can prevent loading native shared lib multiple times by calling clear here.
can you elaborate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't understand why we can prevent loading native shared lib multiple times by calling clear here.
can you elaborate?

At this line, we did not find any supported factories from the list of factories. So we clear it to avoid to twicely check them wether support or not.

String libDir = PathUtils.concatPath(conf.get(PropertyKey.HOME), "lib");
String extensionDir = conf.get(PropertyKey.EXTENSIONS_DIR);
scanLibs(factories, libDir);
scanExtensions(factories, extensionDir);

List<T> eligibleFactories = new ArrayList<>();
for (T factory : factories) {
if (factory.supportsPath(path, conf)) {
LOG.debug("Factory implementation {} is eligible for path {}", factory, path);
eligibleFactories.add(factory);
}
}

eligibleFactories = select(path, conf, factories);
if (eligibleFactories.isEmpty()) {
LOG.warn("No factory implementation supports the path {}", path);
}
Expand Down Expand Up @@ -201,6 +200,7 @@ private void scan(List<File> files, List<T> factories) {
LOG.debug("Discovered a factory implementation {} - {} in jar {}", factory.getClass(),
factory, jarPath);
register(factory, factories);
register(factory);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

  /**
   * The base list of factories, which does not include any lib or extension factories. The only
   * factories in the base list will be built-in factories, and any additional factories
   * registered by tests. All other factories will be discovered and service loaded when extension
   * creation occurs.
   */
  private final List<T> mFactories = new CopyOnWriteArrayList<>();

we modify the basic assumption of what mFactories represents

will it be better to include a new list call mDynamicLoadedFactories?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. If mFactories contains -> return
  2. If mDynamicLoadedFactories contains -> return
  3. If not, renew the mDynamicLoadedFactories?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@apc999 What's your thoughts

Copy link
Contributor Author

@jhonxue jhonxue Sep 24, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. If mFactories contains -> return
  2. If mDynamicLoadedFactories contains -> return
  3. If not, renew the mDynamicLoadedFactories?

Yea, i think it sounds better! By the way, may be that we can add a method "boolean supportsDynamicLoad()" in the public interface ExtensionFactory to distinguish the underFileSystemFactories, the default return is true, likes the existed method "boolean supportsPath(String path, S conf)"，however, the specific underFileSystemFactories which do not support dynamic load can override the method, so we can still only use mFactories.

What's your thoughts? @apc999 @LuQQiu @maobaolong

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer this way, but is it complicated to add the logic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer this way, but is it complicated to add the logic?
Based on your idea, the steps are :
1. If mFactories contains && !supportsDynamicLoad() -> return
2. If mDynamicLoadedFactories contains && !supportsDynamicLoad() -> return
3. If not, renew the mDynamicLoadedFactories?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The workload SGTM, @apc999 @ggezer @yuzhu PTAL

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jiacheliu3 I think we need to make an agreement on how to address this issue. This part is kind of critical and nobody really familiar with it. More eyes need to be pulled in to think of how to load the extension factories

}
} catch (Throwable t) {
LOG.warn("Failed to load jar {}: {}", jar, t.toString());
Expand Down Expand Up @@ -270,4 +270,25 @@ private void unregister(T factory, List<T> factories) {
LOG.debug("Unregistered factory implementation {} - {}", factory.getClass(), factory);
factories.remove(factory);
}

/**
* Selects all the factories that support the given path from the given list of factories.
*
* @param path path
* @param conf configuration of the extension
* @param factories list of factories
* @return list of factories that support the given path which may be an empty list
*/
private List<T> select(String path, S conf, List<T> factories) {
Preconditions.checkNotNull(path, "path may not be null");

List<T> eligibleFactories = new ArrayList<>();
for (T factory : factories) {
if (factory.supportsPath(path, conf)) {
LOG.debug("Factory implementation {} is eligible for path {}", factory, path);
eligibleFactories.add(factory);
}
}
return eligibleFactories;
}
}
1 change: 0 additions & 1 deletion underfs/cephfs/pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,6 @@
<groupId>io.github.opendataio</groupId>
<artifactId>libcephfs</artifactId>
<version>0.0.1</version>
<scope>provided</scope>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose you remove the provided scope, you want to include the libcephfs and related share lib into the ufs shaded with dependencies jar?

Copy link
Contributor Author

@jhonxue jhonxue Sep 22, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose you remove the provided scope, you want to include the libcephfs and related share lib into the ufs shaded with dependencies jar?

Yes, this pr will solve the problem about the libcephfs_jni.so is already loaded in another classloader, so libcephfs can be included.

</dependency>

<!-- Internal dependencies -->
Expand Down