This is an automated email from the ASF dual-hosted git repository.
panyuepeng 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 52f68224cb3 [FLINK-38865][doc] Fix typos and clarify Async I/O
capacity scope (#27387)
52f68224cb3 is described below
commit 52f68224cb30302d3b0b916a8b24a579686f7c41
Author: Vishal Kamlapure <[email protected]>
AuthorDate: Tue Jan 20 16:15:52 2026 +0530
[FLINK-38865][doc] Fix typos and clarify Async I/O capacity scope (#27387)
---
docs/content/docs/dev/datastream/operators/asyncio.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/content/docs/dev/datastream/operators/asyncio.md
b/docs/content/docs/dev/datastream/operators/asyncio.md
index 4c3e3434afb..f7757fb633b 100644
--- a/docs/content/docs/dev/datastream/operators/asyncio.md
+++ b/docs/content/docs/dev/datastream/operators/asyncio.md
@@ -46,7 +46,7 @@ makes up the vast majority of the function's time.
Asynchronous interaction with the database means that a single parallel
function instance can handle many requests concurrently and
receive the responses concurrently. That way, the waiting time can be overlaid
with sending other requests and
-receiving responses. At the very least, the waiting time is amortized over
multiple requests. This leads in most cased to much higher
+receiving responses. At the very least, the waiting time is amortized over
multiple requests. This leads in most cases to much higher
streaming throughput.
{{< img src="/fig/async_io.svg" width="50%" >}}
@@ -69,7 +69,7 @@ efficient than a proper asynchronous client.
## Async I/O API
Flink's Async I/O API allows users to use asynchronous request clients with
data streams. The API handles the integration with
-data streams, well as handling order, event time, fault tolerance, retry
support, etc.
+data streams, as well as handling order, event time, fault tolerance, retry
support, etc.
Assuming one has an asynchronous client for the target database, three parts
are needed to implement a stream transformation
with asynchronous I/O against the database:
@@ -226,7 +226,7 @@ The following three parameters control the asynchronous
operations:
This duration may include multiple retry attempts (if retries are enabled)
and determines when the operation is ultimately considered complete.
This parameter guards against dead/failed requests.
- - **Capacity**: This parameter defines how many asynchronous requests may be
in progress at the same time.
+ - **Capacity**: This parameter defines how many asynchronous requests may be
in progress per parallel instance (subtask) of the async operator at the same
time.
Even though the async I/O approach leads typically to much better
throughput, the operator can still be the bottleneck in
the streaming application. Limiting the number of concurrent requests
ensures that the operator will not
accumulate an ever-growing backlog of pending requests, but that it will
trigger backpressure once the capacity
