davidradl commented on code in PR #26640:
URL: https://github.com/apache/flink/pull/26640#discussion_r2154288974
##########
docs/layouts/shortcodes/generated/expert_rocksdb_section.html:
##########
@@ -14,6 +14,12 @@
<td>Integer</td>
<td>The number of threads (per stateful operator) used to transfer
(download and upload) files in RocksDBStateBackend.If negative, the common (TM)
IO thread pool is used (see cluster.io-pool.size)</td>
</tr>
+ <tr>
+ <td><h5>state.backend.rocksdb.checkpoint.upload-jitter</h5></td>
+ <td style="word-wrap: break-word;">0 ms</td>
+ <td>Duration</td>
+ <td>The time interval used to create jitter for each checkpoint
file upload.</td>
Review Comment:
some thoughts:
I think the docs need to say why you might want to use this option (as per
the Jira text) and what the impact might be. I assume that if we set the jitter
then there is an random delay added to all requests, impacting existing
performance.
- I wonder whether there is a way to check for the rate limitting return
code and only delay those.
- if we add a random delay using the Jitter , is there a case that the
checkpoints might end up out of order?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
