[jira] [Comment Edited] (ACCUMULO-3888) getActiveScans should not eat TableNotFoundException

["Josh Elser (JIRA)" <ji...@apache.org>]

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

Josh Elser edited comment on ACCUMULO-3888 at 6/15/15 7:52 PM:
---------------------------------------------------------------

Was stewing on this last night and this morning. Instead of {{close()}} being a noop, is it possible to make some new Thrift RPC that the scanner could leverage to automatically remove the session from the SessionManager instead of leaving it to expire on its own accord.

* When a Scanner talks to many tabletservers, the Scanner could close the session on the previous server before it switches to the new server
* More RPCs, but more well-defined resource management
* Is at least one extra RPC a concern for all of the Scanners running over {{accumulo.metadata}} as a part of normal operations?
* Would have to re-architect ScannerImpl and ScannerIterator a little bit to get at the "current" or "last" tabletserver to implement {{close()}}
* Is returning {{ActiveScan}} s from {{getActiveScans}} for "old" scanners a concern to begin with?

Any thoughts/discussion would be appreciated. I feel like this is a glaring hole in our grasp on tserver resource management, but I'm also concerned that it would be difficult to implement correctly w/o impacting performance.


was (Author: elserj):
Was stewing on this last night and this morning. Instead of {{close()}} being a noop, is it possible to make some new Thrift RPC that the scanner could leverage to automatically remove the session from the SessionManager instead of leaving it to expire on its own accord.

* When a Scanner talks to many tabletservers, the Scanner could close the session on the previous server before it switches to the new server
* More RPCs, but more well-defined resource management
* Is at least one extra RPC a concern for all of the Scanners running over {{accumulo.metadata}} as a part of normal operations?
* Would have to re-architect ScannerImpl and ScannerIterator a little bit to get at the "current" or "last" tabletserver to implement {{close()}}
* Is returning {{ActiveScan}}s from {{getActiveScans}} for "old" scanners a concern to begin with?

Any thoughts/discussion would be appreciated. I feel like this is a glaring hole in our grasp on tserver resource management, but I'm also concerned that it would be difficult to implement correctly w/o impacting performance.

> getActiveScans should not eat TableNotFoundException
> ----------------------------------------------------
>
>                 Key: ACCUMULO-3888
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3888
>             Project: Accumulo
>          Issue Type: Bug
>          Components: client
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Critical
>             Fix For: 1.8.0
>
>
> Noticed this awkwardness during integration tests running against a real cluster.
> {noformat}
> org.apache.accumulo.core.client.TableNotFoundException: Table (Id=r) does not exist
>  at org.apache.accumulo.core.client.impl.Tables.getTableName(Tables.java:128)
>  at org.apache.accumulo.core.client.impl.ActiveScanImpl.<init>(ActiveScanImpl.java:63)
>  at org.apache.accumulo.core.client.impl.InstanceOperationsImpl.getActiveScans(InstanceOperationsImpl.java:138)
>  at org.apache.accumulo.test.functional.ScanIdIT.testScanId(ScanIdIT.java:151)
> {noformat}
> The table from the previous test was deleted at the end of the test, but, somehow, a tabletserver returned an ActiveScan for that table. When the client tried to unwrap the table ID into a table name, it got a TableNotFoundException.
> Semantically, if a client is asking for active scans on a server, and the server reports a scan for a table the client doesn't think exists, it's reasonable to assume it was just deleted and not return that ActiveScan from the API call.
> Right now, this situation results in an exception back to the client and they get no results.



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