This is an automated email from the ASF dual-hosted git repository.
xushiyan pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/hudi.git
The following commit(s) were added to refs/heads/asf-site by this push:
new e98220e993e [MINOR][DOCS] Update docs for fs based lock provider
(#8508)
e98220e993e is described below
commit e98220e993e897747df2358206c430b48b174f4f
Author: Shiyan Xu <[email protected]>
AuthorDate: Thu Apr 20 15:36:59 2023 +0800
[MINOR][DOCS] Update docs for fs based lock provider (#8508)
---
website/docs/concurrency_control.md | 13 ++++++++++++-
.../versioned_docs/version-0.12.0/concurrency_control.md | 13 +++++++------
.../versioned_docs/version-0.12.1/concurrency_control.md | 13 +++++++------
.../versioned_docs/version-0.12.2/concurrency_control.md | 13 +++++++------
4 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/website/docs/concurrency_control.md
b/website/docs/concurrency_control.md
index 75ef350f8ba..efa7f3212e2 100644
--- a/website/docs/concurrency_control.md
+++ b/website/docs/concurrency_control.md
@@ -51,11 +51,22 @@ There are 4 different lock providers that require different
configurations to be
**`FileSystem`** based lock provider
+FileSystem based lock provider supports multiple writers cross different
jobs/applications based on atomic create/delete operations of the underlying
filesystem.
+
+:::note
+FileSystem based lock provider is not supported with cloud storage like S3 or
GCS.
+:::
+
```
hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.FileSystemBasedLockProvider
-hoodie.write.lock.filesystem.path
+hoodie.write.lock.filesystem.path (optional)
+hoodie.write.lock.filesystem.expire (optional)
```
+When using the FileSystem based lock provider, by default, the lock file will
store into `hoodie.base.path`+`/.hoodie/lock`. You may use a custom folder to
store the lock file by specifying `hoodie.write.lock.filesystem.path`.
+
+In case the lock cannot release during job crash, you can set
`hoodie.write.lock.filesystem.expire` (lock will never expire by default). You
may also delete lock file manually in such situation.
+
**`Zookeeper`** based lock provider
```
diff --git a/website/versioned_docs/version-0.12.0/concurrency_control.md
b/website/versioned_docs/version-0.12.0/concurrency_control.md
index f8172953f74..ad2d1009e02 100644
--- a/website/versioned_docs/version-0.12.0/concurrency_control.md
+++ b/website/versioned_docs/version-0.12.0/concurrency_control.md
@@ -51,8 +51,11 @@ There are 4 different lock providers that require different
configurations to be
**`FileSystem`** based lock provider
-FileSystem based lock provider provides an out-of-box way to support multiple
writers cross different jobs/applications based on atomic
-create/delete operations of the underlying filesystem
+FileSystem based lock provider supports multiple writers cross different
jobs/applications based on atomic create/delete operations of the underlying
filesystem.
+
+:::note
+FileSystem based lock provider is not supported with cloud storage like S3 or
GCS.
+:::
```
hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.FileSystemBasedLockProvider
@@ -60,11 +63,9 @@ hoodie.write.lock.filesystem.path (optional)
hoodie.write.lock.filesystem.expire (optional)
```
-When using the FileSystem based lock provider, by default, the lock file will
store into `hoodie.base.path`+`/.hoodie/lock`,
-in addition, you can use a custom folder to store the lock file by specify
`hoodie.write.lock.filesystem.path`
+When using the FileSystem based lock provider, by default, the lock file will
store into `hoodie.base.path`+`/.hoodie/lock`. You may use a custom folder to
store the lock file by specifying `hoodie.write.lock.filesystem.path`.
-In case the lock cannot release during job crash, you can set
`hoodie.write.lock.filesystem.expire`, provide an expiry time in minutes, lock
will never expire as default.
-you can also delete lock file manually in such situation
+In case the lock cannot release during job crash, you can set
`hoodie.write.lock.filesystem.expire` (lock will never expire by default). You
may also delete lock file manually in such situation.
**`Zookeeper`** based lock provider
diff --git a/website/versioned_docs/version-0.12.1/concurrency_control.md
b/website/versioned_docs/version-0.12.1/concurrency_control.md
index f8172953f74..ad2d1009e02 100644
--- a/website/versioned_docs/version-0.12.1/concurrency_control.md
+++ b/website/versioned_docs/version-0.12.1/concurrency_control.md
@@ -51,8 +51,11 @@ There are 4 different lock providers that require different
configurations to be
**`FileSystem`** based lock provider
-FileSystem based lock provider provides an out-of-box way to support multiple
writers cross different jobs/applications based on atomic
-create/delete operations of the underlying filesystem
+FileSystem based lock provider supports multiple writers cross different
jobs/applications based on atomic create/delete operations of the underlying
filesystem.
+
+:::note
+FileSystem based lock provider is not supported with cloud storage like S3 or
GCS.
+:::
```
hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.FileSystemBasedLockProvider
@@ -60,11 +63,9 @@ hoodie.write.lock.filesystem.path (optional)
hoodie.write.lock.filesystem.expire (optional)
```
-When using the FileSystem based lock provider, by default, the lock file will
store into `hoodie.base.path`+`/.hoodie/lock`,
-in addition, you can use a custom folder to store the lock file by specify
`hoodie.write.lock.filesystem.path`
+When using the FileSystem based lock provider, by default, the lock file will
store into `hoodie.base.path`+`/.hoodie/lock`. You may use a custom folder to
store the lock file by specifying `hoodie.write.lock.filesystem.path`.
-In case the lock cannot release during job crash, you can set
`hoodie.write.lock.filesystem.expire`, provide an expiry time in minutes, lock
will never expire as default.
-you can also delete lock file manually in such situation
+In case the lock cannot release during job crash, you can set
`hoodie.write.lock.filesystem.expire` (lock will never expire by default). You
may also delete lock file manually in such situation.
**`Zookeeper`** based lock provider
diff --git a/website/versioned_docs/version-0.12.2/concurrency_control.md
b/website/versioned_docs/version-0.12.2/concurrency_control.md
index 5dcbcfee6b3..ad2d1009e02 100644
--- a/website/versioned_docs/version-0.12.2/concurrency_control.md
+++ b/website/versioned_docs/version-0.12.2/concurrency_control.md
@@ -51,8 +51,11 @@ There are 4 different lock providers that require different
configurations to be
**`FileSystem`** based lock provider
-FileSystem based lock provider provides an out-of-box way to support multiple
writers cross different jobs/applications based on atomic
-create/delete operations of the underlying filesystem
+FileSystem based lock provider supports multiple writers cross different
jobs/applications based on atomic create/delete operations of the underlying
filesystem.
+
+:::note
+FileSystem based lock provider is not supported with cloud storage like S3 or
GCS.
+:::
```
hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.FileSystemBasedLockProvider
@@ -60,11 +63,9 @@ hoodie.write.lock.filesystem.path (optional)
hoodie.write.lock.filesystem.expire (optional)
```
-When using the FileSystem based lock provider, by default, the lock file will
store into `hoodie.base.path`+`/.hoodie/lock`,
-in addition, you can use a custom folder to store the lock file by specify
`hoodie.write.lock.filesystem.path`
+When using the FileSystem based lock provider, by default, the lock file will
store into `hoodie.base.path`+`/.hoodie/lock`. You may use a custom folder to
store the lock file by specifying `hoodie.write.lock.filesystem.path`.
-In case the lock cannot release during job crash, you can set
`hoodie.write.lock.filesystem.expire`, provide an expiry time in minutes, lock
will never expire as default.
-you can also delete lock file manually in such situation
+In case the lock cannot release during job crash, you can set
`hoodie.write.lock.filesystem.expire` (lock will never expire by default). You
may also delete lock file manually in such situation.
**`Zookeeper`** based lock provider
