You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Alex Petrov (Jira)" <ji...@apache.org> on 2019/11/13 09:01:00 UTC
[jira] [Comment Edited] (CASSANDRA-15351) Allow configuring
timeouts on the per-request basis
[ https://issues.apache.org/jira/browse/CASSANDRA-15351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973136#comment-16973136 ]
Alex Petrov edited comment on CASSANDRA-15351 at 11/13/19 9:00 AM:
-------------------------------------------------------------------
I would say that the propagation mechanism is the same, and only capping mechanism is different. In case proposed in this ticket, we allow potentially longer requests to run and respect client timeout no matter what, and in 2848 we respect server-side timeout if it's lower than the one requested by client. I agree here that it's better to leave some control to Cassandra, let it time-out requests, and use its configuration as a worst-case scenario / cap. My initial thinking was maintenance / bulk-read tasks, but I think this use-case is too narrow and even potentially dangerous, as it opens doors to tip the node over with a wrongly configured query despite node failsafe mechanisms.
There's a stronger point by about not exposing this until we properly fix timeouts for SRP, digests, etc, but this seems to be fixed in [CASSANDRA-12256].
Probably too specific to the code produced for 2848, but there are some good points in the review of the patch as well, which should probably be taken into consideration.
That said, I suggest we close this ticket as a dupe and continue discussion on the original ticket.
was (Author: ifesdjeen):
I would say that the propagation mechanism is the same, and only capping mechanism is different. In case proposed in this ticket, we allow potentially longer requests to run and respect client timeout no matter what, and in 2848 we respect server-side timeout if it's lower than the one requested by client. I agree here that it's better to leave some control to Cassandra, let it time-out requests, and use its configuration as a worst-case scenario / cap.
There's a stronger point by about not exposing this until we properly fix timeouts for SRP, digests, etc, but this seems to be fixed in [CASSANDRA-12256].
Probably too specific to the code produced for 2848, but there are some good points in the review of the patch as well, which should probably be taken into consideration.
That said, I suggest we close this ticket as a dupe and continue discussion on the original ticket.
> Allow configuring timeouts on the per-request basis
> ---------------------------------------------------
>
> Key: CASSANDRA-15351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15351
> Project: Cassandra
> Issue Type: New Feature
> Components: Messaging/Client
> Reporter: Alex Petrov
> Assignee: Yifan Cai
> Priority: Normal
>
> Some queries need to be ran with a higher timeout value, which should be possible without allowing _all_ requests to be above this value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org