[flink] branch master updated: [FLINK-27466][jdbc][docs] Clarify metaspace leak fix

[ch...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

chesnay pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/flink.git


The following commit(s) were added to refs/heads/master by this push:
     new 99c9c2ee3d4 [FLINK-27466][jdbc][docs] Clarify metaspace leak fix
99c9c2ee3d4 is described below

commit 99c9c2ee3d4cf15319ca9f97b61b18f3f3b23210
Author: Chesnay Schepler <ch...@apache.org>
AuthorDate: Thu Jun 23 13:37:57 2022 +0200

    [FLINK-27466][jdbc][docs] Clarify metaspace leak fix
---
 docs/content.zh/docs/ops/debugging/debugging_classloading.md | 4 +++-
 docs/content/docs/ops/debugging/debugging_classloading.md    | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/docs/content.zh/docs/ops/debugging/debugging_classloading.md b/docs/content.zh/docs/ops/debugging/debugging_classloading.md
index e08c9c0bf4d..c82026a5f7e 100644
--- a/docs/content.zh/docs/ops/debugging/debugging_classloading.md
+++ b/docs/content.zh/docs/ops/debugging/debugging_classloading.md
@@ -167,7 +167,9 @@ Common causes for class leaks and suggested fixes:
     interners, or Avro's class/object caches in the serializers.
 
   - *JDBC*: JDBC drivers leak references outside the user code classloader. To ensure that these classes are only loaded once
-   you should either add the driver jars to Flink's `lib/` folder, or add the driver classes to the list of parent-first loaded class via [`classloader.parent-first-patterns-additional`]({{< ref "docs/deployment/config" >}}#classloader-parent-first-patterns-additional).
+   you should add the driver jars to Flink's `lib/` folder instead of bundling them in the user-jar.
+   If you can't guarantee that none of your user-jars bundle the driver, you have to additionally add the driver classes to the list of parent-first
+   loaded classes via [`classloader.parent-first-patterns-additional`]({{< ref "docs/deployment/config" >}}#classloader-parent-first-patterns-additional).
 
 A helpful tool for unloading dynamically loaded classes are the user code class loader release hooks. These are hooks which are executed prior to the unloading of a classloader. It is generally recommended to shutdown and unload resources as part of the regular function lifecycle (typically the `close()` methods). But in some cases (for example for static fields), it is better to unload once a classloader is certainly not needed anymore.
 
diff --git a/docs/content/docs/ops/debugging/debugging_classloading.md b/docs/content/docs/ops/debugging/debugging_classloading.md
index 7a65bff44c2..a5ad594e9d7 100644
--- a/docs/content/docs/ops/debugging/debugging_classloading.md
+++ b/docs/content/docs/ops/debugging/debugging_classloading.md
@@ -166,7 +166,9 @@ Common causes for class leaks and suggested fixes:
     interners, or Avro's class/object caches in the serializers.
 
   - *JDBC*: JDBC drivers leak references outside the user code classloader. To ensure that these classes are only loaded once
-   you should either add the driver jars to Flink's `lib/` folder, or add the driver classes to the list of parent-first loaded class via [`classloader.parent-first-patterns-additional`]({{< ref "docs/deployment/config" >}}#classloader-parent-first-patterns-additional).
+   you should add the driver jars to Flink's `lib/` folder instead of bundling them in the user-jar. 
+   If you can't guarantee that none of your user-jars bundle the driver, you have to additionally add the driver classes to the list of parent-first
+   loaded classes via [`classloader.parent-first-patterns-additional`]({{< ref "docs/deployment/config" >}}#classloader-parent-first-patterns-additional).
 
 A helpful tool for unloading dynamically loaded classes are the user code class loader release hooks. These are hooks which are executed prior to the unloading of a classloader. It is generally recommended to shutdown and unload resources as part of the regular function lifecycle (typically the `close()` methods). But in some cases (for example for static fields), it is better to unload once a classloader is certainly not needed anymore.