adelapena commented on a change in pull request #1224:
URL: https://github.com/apache/cassandra/pull/1224#discussion_r718326096
##########
File path: conf/cassandra.yaml
##########
@@ -897,6 +897,19 @@ sstable_preemptive_open_interval_in_mb: 50
# When unset, the default is 200 Mbps or 25 MB/s
# inter_dc_stream_throughput_outbound_megabits_per_sec: 200
+# Server sides timeouts for requests. The server will return a timeout
exception
Review comment:
Wouldn't it be `server side timeouts` or `server-side timeouts`?
##########
File path: conf/cassandra.yaml
##########
@@ -897,6 +897,19 @@ sstable_preemptive_open_interval_in_mb: 50
# When unset, the default is 200 Mbps or 25 MB/s
# inter_dc_stream_throughput_outbound_megabits_per_sec: 200
+# Server sides timeouts for requests. The server will return a timeout
exception
+# to the client if it can't complete an operation within the corresponding
+# timeout. Those settings are a protection against:
+# 1) having client wait on an operation that might never terminate due to
some
+# failures.
+# 2) operations that uses too much CPU/reads too much data (leading to
memory build
Review comment:
```suggestion
# 2) operations that use too much CPU/read too much data (leading to
memory build
```
##########
File path: conf/cassandra.yaml
##########
@@ -897,6 +897,19 @@ sstable_preemptive_open_interval_in_mb: 50
# When unset, the default is 200 Mbps or 25 MB/s
# inter_dc_stream_throughput_outbound_megabits_per_sec: 200
+# Server sides timeouts for requests. The server will return a timeout
exception
+# to the client if it can't complete an operation within the corresponding
+# timeout. Those settings are a protection against:
+# 1) having client wait on an operation that might never terminate due to
some
+# failures.
+# 2) operations that uses too much CPU/reads too much data (leading to
memory build
+# up) by putting a limit to how long an operation will execute.
+# For this reason, you should avoid putting these settings too high. Of course
+# putting them too low is equally ill-advised since clients could get timeouts
even
+# for successful operations just because the timeout setting is too tight.
+# In other words, if you are timing out requests because of underlying
resource constraints
+# then increasing the timeout will just cause more problems.
Review comment:
This paragraph talks about too high, too low, and then too high again.
Maybe we could rearrange the order to:
```suggestion
# For this reason, you should avoid putting these settings too high. In
other words,
# if you are timing out requests because of underlying resource constraints
then
# increasing the timeout will just cause more problems. Of course putting
them too
# low is equally ill-advised since clients could get timeouts even for
successful
# operations just because the timeout setting is too tight.
```
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
