You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "Eric Owhadi (JIRA)" <ji...@apache.org> on 2015/09/06 14:54:45 UTC

[jira] [Work started] (TRAFODION-1485) Patch for hbase.client.scanner.timeout.period logic until fix in hbase is available

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

Work on TRAFODION-1485 started by Eric Owhadi.
----------------------------------------------
> Patch for hbase.client.scanner.timeout.period logic until fix in hbase is available
> -----------------------------------------------------------------------------------
>
>                 Key: TRAFODION-1485
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-1485
>             Project: Apache Trafodion
>          Issue Type: Bug
>          Components: sql-exe
>    Affects Versions: 1.1 (pre-incubation)
>            Reporter: Eric Owhadi
>            Assignee: Eric Owhadi
>              Labels: patch
>
>  We have been facing a situation on trafodion, where we are  hitting the hbase.client.scanner.timeout.period scenario:
> basically, when doing queries that require spilling to disk because of high complexity of what is involved, the underlying hbase scanner serving one of the operation involved in the complex query cannot call the next() withing the timeout specify... too busy taking care of other business.
> This is legit scenario, and I was wondering why in the code, special care is done to make sure that client side, if a DNRIOE of type unknownScannerException shows up, and the hbase.client.scanner.timeout.period time elapsed, we make sure to throw a scannerTimeoutException, instead of just let it go and reset scanner.



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