cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10125) ReadFailure is thrown instead of ReadTimeout for range queries
Date Fri, 21 Aug 2015 08:09:45 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706379#comment-14706379
] 

Sylvain Lebresne commented on CASSANDRA-10125:
----------------------------------------------

Committed, thanks.

bq. Is the plan to keep using two verbs to drive the different timeouts?

I don't have particular plan to change it, mostly because I don't see much drawback at using
the 2 verbs (even if it's just for the timeout).


> ReadFailure is thrown instead of ReadTimeout for range queries
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-10125
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10125
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 3.0 beta 2
>
>
> CASSANDRA-8099 merged the way single partition and range read messages where handled
and has switch to using the same verb ({{Verb.READ}}) for both, effectively deprecating {{Verb.RANGE_SLICE}}.
Unfortunately, we are relying on having 2 different verbs for timeouts. More precisely, when
adding a callback in the expiring map of {{MessagingService}}, we use the timeout from the
{{Verb}}. As a consequence, it's currently set with the single partition read timeout (5s)
even for range queries (which have a 10s timeout).  And when a callback expires, it is notified
as a failure to the callback (which is debatable imo but a separate issue), which means range
queries will generally send a ReadFailure (after 5s) instead of a ReadTimeout (since they
do wait 10s before sending those).
> That is the reason for at least the failure of {{nosetests replace_address_test:TestReplaceAddress.replace_first_boot_test}}
dtest (the test has 3 nodes, kill one and expects a timeout at CL.THREE but get a failure
instead).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message