Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 82F7C11E3F for ; Mon, 4 Aug 2014 01:45:35 +0000 (UTC) Received: (qmail 83944 invoked by uid 500); 4 Aug 2014 01:45:35 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 83885 invoked by uid 500); 4 Aug 2014 01:45:35 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 83875 invoked by uid 99); 4 Aug 2014 01:45:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Aug 2014 01:45:35 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of wilhelm.von.cloud@accumulo.net does not designate 209.85.213.51 as permitted sender) Received: from [209.85.213.51] (HELO mail-yh0-f51.google.com) (209.85.213.51) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Aug 2014 01:45:30 +0000 Received: by mail-yh0-f51.google.com with SMTP id f73so3942661yha.38 for ; Sun, 03 Aug 2014 18:45:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JGlrLhzvFpOD2VBKYUH9s16Ti2Q0lUffBJp8+P65yJw=; b=dyJSDt/234WNvTiTFxe5j2ATHVmYrAaz8XqRpZG9D5xVKlGsZnEoQZF6Pg+HvZFDbJ hY62Pq09yE31dj37/9u1f/fmBxK+SRx1QBrHDL5CiM2licItR9yLEruGZCbIlU1JPNI3 S1ZMgu0v2GeUtIss/3ttI2QXM3aMhPCnuBvg5m3WjA/scBkGQR6Aj7hIU32acPo11PCZ gxJOAbfuKBkkyXG93QXyV0Qtia2CC5cSMISMlDZvihjjA/8zg52DqJrhTibIuEZ6zV2f 5J7KmUp4pWsRdsVDDOcaENLrdlwq3vsXUbsAzpcV4hAvwAg9gHhjh5UHJhMuu7K5tEuR p3PQ== X-Gm-Message-State: ALoCoQkCftmQc7Teq/EtUASi05AFO2FFPUf2BIYosija/1AuJfhTA9x6wYzNA5jwaxj7lIE0lRvs MIME-Version: 1.0 X-Received: by 10.236.84.134 with SMTP id s6mr33714838yhe.38.1407116709118; Sun, 03 Aug 2014 18:45:09 -0700 (PDT) Received: by 10.170.221.66 with HTTP; Sun, 3 Aug 2014 18:45:09 -0700 (PDT) X-Originating-IP: [98.117.207.73] In-Reply-To: References: <53DEA417.1020608@gmail.com> Date: Sun, 3 Aug 2014 21:45:09 -0400 Message-ID: Subject: Re: 'scanner closed' error From: William Slacum To: user@accumulo.apache.org Content-Type: multipart/alternative; boundary=20cf301b69cf9ae8a204ffc3e39a X-Virus-Checked: Checked by ClamAV on apache.org --20cf301b69cf9ae8a204ffc3e39a Content-Type: text/plain; charset=UTF-8 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 < don.resnik@objectivesolutions.com> 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 wrote: > >> Don, >> >> Does this describe your error? >> >> 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 TabletServerBatchReaderIterator. 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, >>> >> > --20cf301b69cf9ae8a204ffc3e39a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have seen issues if I don't have an explicit close o= n the batch scanner. When I don't have the close, the gc ends up callin= g `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 <don.resnik@objectivesolutio= ns.com> wrote:
Josh,

Th= anks for the response. =C2=A0I did see that ticket in my initial research. = =C2=A0 If I understood correctly, that ticket makes it sound like the scann= er was closed programmatically with threads still running, so there was not= really an error. =C2=A0In my case, the error is coming up well before the = scanner has completed. =C2=A0We did not intend to programmatically close th= e scanner where is it closing on us, but I will confirm this week that we d= o not have a condition that would cause the scanner to close prematurely wi= th threads still running.

Thanks,

Don Resnik
<= br>



On Sun, Aug 3, 201= 4 at 5:05 PM, Josh Elser <josh.elser@gmail.com> wrote:
Don,

Does this describe your error?

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. =C2=A0The query begins to return values but then stops with = a
'scanner closed' error. =C2=A0The only reference I can find to scan= ner closed
in the src is in TabletServerBatchReaderIterator. =C2=A0I can see th= at the
error is thrown when the query thread pool is shutdown, but I am not
sure why this is happening. =C2=A0This 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. =C2=A0Any info on what conditions would<= br> lead to a scanner closed error and where to begin looking to resolve
would be appreciated.

Thanks,


--20cf301b69cf9ae8a204ffc3e39a--