[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645138#comment-14645138
]
Russ Weeks commented on ACCUMULO-3931:
--------------------------------------
Sorry to drag this up again: I understand that multiple repeated calls to
iterator() on a batch scanner will consume resources in a common thread pool
and could lead to starvation. Is there some way to release those threads
without consuming the whole iterator? eg. if I call scanner.setRanges, will
that do it? or do I have to call scanner.close()?
The use case is, my code is retrieving the first n kv pairs for a given set of
ranges (yeah I get that the order of the returned keys is not guaranteed with a
batch scanner) and I'm hoping that I can reuse a single scanner, not close it
and re-open it for every invocation.
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> -------------------------------------------------------------------------------------------
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
> Affects Versions: 1.6.3, 1.7.0
> Reporter: Russ Weeks
> Assignee: Eric Newton
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
