[
https://issues.apache.org/jira/browse/ACCUMULO-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427038#comment-13427038
]
Chris Waring commented on ACCUMULO-705:
---------------------------------------
Keith believe option (1) is preferable. Within this option there are two
choices I see.
(1) As soon as the timeout is hit, throw an exception and whatever data has
been returned is it
(2) Do not propagate the exception up until there is no more work for the
threads expect for the tserver that is pooged. At this point you've serviced as
much of the request as possible.
(1) seems simpler.
(2) seems a bit more complete.
> Batch Scanner needs timeout
> ---------------------------
>
> Key: ACCUMULO-705
> URL: https://issues.apache.org/jira/browse/ACCUMULO-705
> Project: Accumulo
> Issue Type: New Feature
> Components: client
> Reporter: Keith Turner
> Assignee: Keith Turner
> Fix For: 1.5.0
>
>
> The batch scanner needs a user configurable time out. When the batch scanner
> is used to query lots of tablet in parallel, if one tablet or tablet server
> is unavailable for some reason it will cause the scan to hang indefinitely.
> Users need more control over this behavior.
> It seems like the batch scanner could behave in one of the following ways :
> * Read as much data as possible, then throw an exception when a tablet or
> tablet server has timed out
> * Throw an exception as soon as a tablet or tablet server times out, even
> if data could still be read from other tablets successfully.
> The timeout can default to max long to preserve the current behavior.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
