[
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)
