I can't really say what the web service is doing, but I would assume
that it should handling this for you. You, as a client, shouldn't be
having to introspect the response body/msg to determine what to do. It
sounds like this REST service has a bug.
I think I also led you astray. The ticket I sent you was about a log
message, not an actual Exception being thrown up the stack (which I
assume is what's happening).
The number of ranges is likely irrelevant to what you're seeing. Look at
the implementation of your REST service and figure out what exactly is
happening (where/why is the Exception thrown). If you can provide more
details about how the service is actually implemented, we might be able
to give more details.
On 8/4/14, 9:45 AM, Don Resnik wrote:
Bill/Josh,
Thanks for the info. After looking at it today, I am more inclined to
think that the iterator is actually working properly and I an just
getting the 500-Scanner Closed error at the end of the scan due to the
ticket that Josh noted.
So, given that, I have two questions:
1. Is it ok to just code around the error handling for this particular
error? Currently we call this logic via REST web service and we loop
thorough the HTTP-200 responses until we get a HTTP-204. If we get any
HTTP-400+ responses we close the query and throw an exception. If I add
an additional conditional before the HTTP-400+ check to check for
HTTP-500 and errorMessage.indexOf("scanner closed") then just break out
of the loop and continue processing, but do not throw an error, would
that work?
2. Could this issue come from using a BatchScanner with a single
range? The query is not sure if it is going to get 1 or more ranges, so
we use a BatchScanner either way. Should I alter the code to use a
Scanner once I know I only have one range?
Thanks for your insight.
Don Resnik
On Sun, Aug 3, 2014 at 9:45 PM, William Slacum
<[email protected] <mailto:[email protected]>>
wrote:
I have seen issues if I don't have an explicit close on the batch
scanner. When I don't have the close, the gc ends up calling
`finalize()` which closes the thread pool. Basically, the work
around is to manage the lifetime of the instance yourself, rather
than leave it up to fate.
On Sun, Aug 3, 2014 at 7:03 PM, Don Resnik
<[email protected]
<mailto:[email protected]>> wrote:
Josh,
Thanks for the response. I did see that ticket in my initial
research. If I understood correctly, that ticket makes it
sound like the scanner was closed programmatically with threads
still running, so there was not really an error. In my case,
the error is coming up well before the scanner has completed.
We did not intend to programmatically close the scanner where
is it closing on us, but I will confirm this week that we do not
have a condition that would cause the scanner to close
prematurely with threads still running.
Thanks,
Don Resnik
On Sun, Aug 3, 2014 at 5:05 PM, Josh Elser <[email protected]
<mailto:[email protected]>> wrote:
Don,
Does this describe your error?
https://issues.apache.org/__jira/browse/ACCUMULO-607
<https://issues.apache.org/jira/browse/ACCUMULO-607>
On 8/3/14, 4:50 PM, Don Resnik wrote:
I have some query logic that uses a stack of custom
iterators with a
batch scanner. The query begins to return values but
then stops with a
'scanner closed' error. The only reference I can find
to scanner closed
in the src is in TabletServerBatchReaderIterato__r. I
can see that the
error is thrown when the query thread pool is shutdown,
but I am not
sure why this is happening. This query logic works on a
single node
instance, but I get the scanner closed error when
running on a multi-node
cluster.
So far the stack traces have not been very helpful and
we are not sure
where or how to troubleshoot this. Any info on what
conditions would
lead to a scanner closed error and where to begin
looking to resolve
would be appreciated.
Thanks,
