[HOTFIX] [DOCS] fix error in leger api document
This PR :
1. add missing comma and dot
2. fix some layout error
in ledger-api document
Reviewers: Sijie Guo <None>
This closes #2250 from aloyszhang/hotfix-ledger-api
diff --git a/site/docs/4.10.0/api/ledger-api.md b/site/docs/4.10.0/api/ledger-api.md
index adf2961..a349492 100644
--- a/site/docs/4.10.0/api/ledger-api.md
+++ b/site/docs/4.10.0/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.5.0/api/ledger-api.md b/site/docs/4.5.0/api/ledger-api.md
index 4e1070d..7507cc7 100644
--- a/site/docs/4.5.0/api/ledger-api.md
+++ b/site/docs/4.5.0/api/ledger-api.md
@@ -155,8 +155,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -172,7 +172,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -186,9 +186,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -196,6 +194,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.5.1/api/ledger-api.md b/site/docs/4.5.1/api/ledger-api.md
index 031389c..17db9a3 100644
--- a/site/docs/4.5.1/api/ledger-api.md
+++ b/site/docs/4.5.1/api/ledger-api.md
@@ -155,8 +155,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -172,7 +172,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -186,9 +186,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -196,6 +194,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.6.0/api/ledger-api.md b/site/docs/4.6.0/api/ledger-api.md
index acde8d6..3f8f478 100644
--- a/site/docs/4.6.0/api/ledger-api.md
+++ b/site/docs/4.6.0/api/ledger-api.md
@@ -155,8 +155,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed BookKeeper, guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -172,7 +172,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -186,9 +186,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -196,6 +194,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.6.1/api/ledger-api.md b/site/docs/4.6.1/api/ledger-api.md
index c247bfb..ac687d5 100644
--- a/site/docs/4.6.1/api/ledger-api.md
+++ b/site/docs/4.6.1/api/ledger-api.md
@@ -218,8 +218,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -235,7 +235,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -249,9 +249,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -259,6 +257,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.6.2/api/ledger-api.md b/site/docs/4.6.2/api/ledger-api.md
index 2007e71..8407a2a 100644
--- a/site/docs/4.6.2/api/ledger-api.md
+++ b/site/docs/4.6.2/api/ledger-api.md
@@ -218,8 +218,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -235,7 +235,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -249,9 +249,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -259,6 +257,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.7.0/api/ledger-api.md b/site/docs/4.7.0/api/ledger-api.md
index edb67f5..862954a 100644
--- a/site/docs/4.7.0/api/ledger-api.md
+++ b/site/docs/4.7.0/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.7.1/api/ledger-api.md b/site/docs/4.7.1/api/ledger-api.md
index d44437b..02129df 100644
--- a/site/docs/4.7.1/api/ledger-api.md
+++ b/site/docs/4.7.1/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.7.2/api/ledger-api.md b/site/docs/4.7.2/api/ledger-api.md
index c22daeb..9ce93b8 100644
--- a/site/docs/4.7.2/api/ledger-api.md
+++ b/site/docs/4.7.2/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.7.3/api/ledger-api.md b/site/docs/4.7.3/api/ledger-api.md
index 5d69cb1..2c79794 100644
--- a/site/docs/4.7.3/api/ledger-api.md
+++ b/site/docs/4.7.3/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.8.0/api/ledger-api.md b/site/docs/4.8.0/api/ledger-api.md
index 2b44d47..03ea708 100644
--- a/site/docs/4.8.0/api/ledger-api.md
+++ b/site/docs/4.8.0/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.8.1/api/ledger-api.md b/site/docs/4.8.1/api/ledger-api.md
index 8147d39..51890b7 100644
--- a/site/docs/4.8.1/api/ledger-api.md
+++ b/site/docs/4.8.1/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.8.2/api/ledger-api.md b/site/docs/4.8.2/api/ledger-api.md
index b6cb0f0..cd46e99 100644
--- a/site/docs/4.8.2/api/ledger-api.md
+++ b/site/docs/4.8.2/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.9.0/api/ledger-api.md b/site/docs/4.9.0/api/ledger-api.md
index 15d2829..65af132 100644
--- a/site/docs/4.9.0/api/ledger-api.md
+++ b/site/docs/4.9.0/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.9.1/api/ledger-api.md b/site/docs/4.9.1/api/ledger-api.md
index 0898469..c1dc8ec 100644
--- a/site/docs/4.9.1/api/ledger-api.md
+++ b/site/docs/4.9.1/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/4.9.2/api/ledger-api.md b/site/docs/4.9.2/api/ledger-api.md
index c0817e9..fa112fb 100644
--- a/site/docs/4.9.2/api/ledger-api.md
+++ b/site/docs/4.9.2/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
diff --git a/site/docs/latest/api/ledger-api.md b/site/docs/latest/api/ledger-api.md
index 38f436d..e35ebab 100644
--- a/site/docs/latest/api/ledger-api.md
+++ b/site/docs/latest/api/ledger-api.md
@@ -180,8 +180,8 @@
### Reading entries after the LastAddConfirmed range
`readUnconfirmedEntries` allowing to read after the LastAddConfirmed range.
-It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet
-For entries which are within the range 0..LastAddConfirmed BookKeeper guarantees that the writer has successfully received the acknowledge.
+It lets the client read without checking the local value of LastAddConfirmed, so that it is possible to read entries for which the writer has not received the acknowledge yet.
+For entries which are within the range 0..LastAddConfirmed, BookKeeper guarantees that the writer has successfully received the acknowledge.
For entries outside that range it is possible that the writer never received the acknowledge and so there is the risk that the reader is seeing entries before the writer and this could result in a consistency issue in some cases.
With this method you can even read entries before the LastAddConfirmed and entries after it with one call, the expected consistency will be as described above.
@@ -197,7 +197,7 @@
## Deleting ledgers
-{% pop Ledgers %} can also be deleted synchronously or asynchronously.
+{% pop Ledgers %} can be deleted synchronously which may throw exception:
```java
long ledgerId = 1234;
@@ -211,9 +211,7 @@
### Delete entries asynchronously
-Exceptions thrown:
-
-*
+{% pop Ledgers %} can also be deleted asynchronously:
```java
class DeleteEntryCallback implements AsyncCallback.DeleteCallback {
@@ -221,6 +219,7 @@
System.out.println("Delete completed");
}
}
+bkClient.asyncDeleteLedger(ledgerID, new DeleteEntryCallback(), null);
```
## Simple example
