1u0 commented on a change in pull request #9169: [FLINK-12998][docs] Update
documentation for file systems loading as plugins
URL: https://github.com/apache/flink/pull/9169#discussion_r309558716
##########
File path: docs/monitoring/debugging_classloading.md
##########
@@ -28,17 +28,20 @@ under the License.
## Overview of Classloading in Flink
When running Flink applications, the JVM will load various classes over time.
-These classes can be divided into two domains:
+These classes can be divided into three groups based on their origin:
- The **Java Classpath**: This is Java's common classpath, and it includes
the JDK libraries, and all code
- in Flink's `/lib` folder (the classes of Apache Flink and its core
dependencies).
+ in Flink's `/lib` folder (the classes of Apache Flink and some
dependencies).
+
+ - The **Flink Plugin Components**: The plugins code in folders under Flink's
`/plugins` folder. Flink's plugin mechanism will dynamically load them once
during startup.
- The **Dynamic User Code**: These are all classes that are included in the
JAR files of dynamically submitted jobs,
(via REST, CLI, web UI). They are loaded (and unloaded) dynamically per
job.
-What classes are part of which domain depends on the particular setup in which
you run Apache Flink. As a general rule, whenever you start the Flink
-processes first, and submit jobs, the job's classes are loaded dynamically. If
the Flink processes are started together with the job/application,
-or the application spawns the Flink components (JobManager, TaskManager, etc.)
then all classes are in the Java classpath.
+As a general rule, whenever you start the Flink processes first and submit
jobs later, the job's classes are loaded dynamically.
+If the Flink processes are started together with the job/application, or if
the application spawns the Flink components (JobManager, TaskManager, etc.),
then all job's classes are in the Java classpath.
+
+Code in plugin components is loaded dynamically once by a dedicated class
loader per plugin.
Review comment:
I'd avoid giving such claim.
Currently, a dedicated class loader per plugin provide common java class
loading isolation and not more.
It's assumed that a reader is familiar with java class loading. Imo,
extending this sentence as you propose raises more questions from the reader.
----------------------------------------------------------------
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]
With regards,
Apache Git Services
