You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "David Alves (JIRA)" <ji...@apache.org> on 2016/12/09 04:44:58 UTC

[jira] [Resolved] (KUDU-1656) Scanner timeouts aren't retried when waiting on a transaction

     [ https://issues.apache.org/jira/browse/KUDU-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Alves resolved KUDU-1656.
-------------------------------
       Resolution: Fixed
         Assignee: David Alves
    Fix Version/s: 1.2.0

This got solved as part of KUDU-798

> Scanner timeouts aren't retried when waiting on a transaction
> -------------------------------------------------------------
>
>                 Key: KUDU-1656
>                 URL: https://issues.apache.org/jira/browse/KUDU-1656
>             Project: Kudu
>          Issue Type: Bug
>          Components: tserver
>            Reporter: Jean-Daniel Cryans
>            Assignee: David Alves
>             Fix For: 1.2.0
>
>
> I recently changed ITClient to use READ_AT_SNAPSHOT scanners and we've been seeing errors like this:
> {noformat}
> 19:56:29.459 [WARN - New I/O worker #169] (AsyncKuduScanner.java:407) Can not open scanner
> org.apache.kudu.client.NonRecoverableException: could not wait for desired snapshot timestamp to be consistent: Timed out waiting for all transactions with ts < P: 1475006188645381 usec, L: 0 to commit
> 	at org.apache.kudu.client.TabletClient.dispatchTSErrorOrReturnException(TabletClient.java:548)
> 	at org.apache.kudu.client.TabletClient.decode(TabletClient.java:482)
> 	at org.apache.kudu.client.TabletClient.decode(TabletClient.java:83)
> {noformat}
> Since this comes back as a TimedOut AppStatus, neither clients are retrying the error which doesn't seem to be the expected behavior on the server-side: https://github.com/cloudera/kudu/blob/be719edc3581802e094c3af6a88d67acba44ba71/src/kudu/tserver/tablet_service.cc#L1764
> One one hand it seems weird to rely on the user to retry only certain timeouts, OTOH maybe it shouldn't be sent as a timeout? But I'm not sure what it should be.



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