Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Sun, 15 Feb 2015 19:14:11 +0000 (UTC)
From: "Hanifi Gunes (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.12775211.1424010320000.51711.1424027651496@Atlassian.JIRA>
In-Reply-To: <JIRA.12775211.1424010320000@Atlassian.JIRA>
References: <JIRA.12775211.1424010320000@Atlassian.JIRA>
 <JIRA.12775211.1424010320614@arcas>
Subject: [jira] [Commented] (DRILL-2252) Cancelling a fragment is not
 cleaning up RecordBatches
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DRILL-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322152#comment-14322152 ] 

Hanifi Gunes commented on DRILL-2252:
-------------------------------------

Never mind the above comment. The method seems to check on a guard variable *closed* that should ensure at most once semantics.

> Cancelling a fragment is not cleaning up RecordBatches
> ------------------------------------------------------
>
>                 Key: DRILL-2252
>                 URL: https://issues.apache.org/jira/browse/DRILL-2252
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Execution - Flow
>            Reporter: Venki Korukanti
>            Assignee: Venki Korukanti
>         Attachments: DRILL-2252-1.patch
>
>
> Currently FragmentExecutor exits out of processing loop once a fragment is cancelled, but it is not cleaning up the operators. This causes some operators to leak resources. For example ScanBatch closes the currently open files as part of the cleanup, because of this bug now it leaves some open files.
> To repro:
> Run a query that involves LIMIT in loop and observe the memory used by the Drillbit go up consistently. 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)