Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 7116A200C85 for ; Tue, 30 May 2017 20:16:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 6FA67160BDC; Tue, 30 May 2017 18:16:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B98BD160BB1 for ; Tue, 30 May 2017 20:16:07 +0200 (CEST) Received: (qmail 74144 invoked by uid 500); 30 May 2017 18:16:07 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 74133 invoked by uid 99); 30 May 2017 18:16:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 May 2017 18:16:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 6C67A1A7B17 for ; Tue, 30 May 2017 18:16:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id i2CqVWz3P9Kj for ; Tue, 30 May 2017 18:16:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 490F35FDAD for ; Tue, 30 May 2017 18:16:05 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id CE87BE0D3C for ; Tue, 30 May 2017 18:16:04 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4480521B5B for ; Tue, 30 May 2017 18:16:04 +0000 (UTC) Date: Tue, 30 May 2017 18:16:04 +0000 (UTC) From: "Ivan Bella (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ACCUMULO-4643) Allow iterators to interrupt themselves MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 30 May 2017 18:16:08 -0000 [ https://issues.apache.org/jira/browse/ACCUMULO-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029865#comment-16029865 ] Ivan Bella commented on ACCUMULO-4643: -------------------------------------- [~kturner] You are correct in that whatever key gets sent back with the exception (or the "interrupt" key) would have to be transformed. In fact it would need contain enough information such that the subsequent seek invocation (using that key as the start of the range, non-inclusive) will allow the seek to continue where it left off. Option #2 seemed simpler to implement initially. I am going to implement an option #3 where I create a interface that can be used to extend an SKVI with methods to implement this concept instead of using an exception. Option #1 seemed like a potential performance problem as we would need to check the class of the returned key on every cycle. It is thought that an iterator that yields using an exception would only be implemented with iterators that may do a lot of work for no gain and hence this would happen infrequently. > Allow iterators to interrupt themselves > --------------------------------------- > > Key: ACCUMULO-4643 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4643 > Project: Accumulo > Issue Type: Improvement > Components: tserver > Affects Versions: 1.8.1, 2.0.0 > Reporter: Ivan Bella > Assignee: Ivan Bella > Labels: features > Fix For: 2.0.0 > > Time Spent: 6h 10m > Remaining Estimate: 0h > > The idea here is to allow an iterator stack to send back a special key or throw a special exception which will allow the tablet server to tear down the scan to be rebuilt later. This is to handle the case where an iterator is doing a lot of work without returning results to avoid starving out other scans. > There are two thoughts on how to do this: > 1) A special "interrupt" key is returned from the getTopKey call that is detected in the Tablet.nextBatch call, is not added to the results, but is used to add an unfinished range and results in the remaining ranges to be deemed unfinished. > 2) An special exception is thrown from the next or seek call that included the key of the current position, and the same actions are taken as in 1). -- This message was sent by Atlassian JIRA (v6.3.15#6346)