Return-Path: X-Original-To: apmail-phoenix-dev-archive@minotaur.apache.org Delivered-To: apmail-phoenix-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6931C18A24 for ; Tue, 5 Jan 2016 05:18:50 +0000 (UTC) Received: (qmail 71482 invoked by uid 500); 5 Jan 2016 05:18:50 -0000 Delivered-To: apmail-phoenix-dev-archive@phoenix.apache.org Received: (qmail 71417 invoked by uid 500); 5 Jan 2016 05:18:50 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 71406 invoked by uid 99); 5 Jan 2016 05:18:50 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2016 05:18:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 81045C0058 for ; Tue, 5 Jan 2016 05:18:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.554, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id DGtnX0nb3crz for ; Tue, 5 Jan 2016 05:18:42 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with SMTP id 593CC20DB6 for ; Tue, 5 Jan 2016 05:18:41 +0000 (UTC) Received: (qmail 70223 invoked by uid 99); 5 Jan 2016 05:18:40 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2016 05:18:40 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id E573F2C1F62 for ; Tue, 5 Jan 2016 05:18:39 +0000 (UTC) Date: Tue, 5 Jan 2016 05:18:39 +0000 (UTC) From: "James Taylor (JIRA)" To: dev@phoenix.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-2556) Subqueries with nested joins may not free hash cache MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PHOENIX-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15082397#comment-15082397 ] James Taylor commented on PHOENIX-2556: --------------------------------------- Thanks for following up on this, [~maryannxue]. The TxCheckpointIT failure is likely related to the same cause, as the test causing the failure, testCheckpointForDeleteAndUpsert, is doing subqueries (when ignored the test passes). It's slightly different, though, as it's doing a subquery in a delete. Could that be a slightly different case of this bug? Also, minor nit - would you mind adding an error message for the new assert in ConnectionQueryServicesTestImpl, like this? {code} @Override public void close() throws SQLException { try { Set connections = this.connections; this.connections = Sets.newHashSet(); SQLCloseables.closeAll(connections); long unfreedBytes = clearCache(); assertEquals("Found unfreed bytes in server-side cache", 0,unfreedBytes); } finally { super.close(); } } {code} Not sure about the other failures - I'm still on JDK 7. Would be good to file JIRAs on them if they fail consistently, though. > Subqueries with nested joins may not free hash cache > ---------------------------------------------------- > > Key: PHOENIX-2556 > URL: https://issues.apache.org/jira/browse/PHOENIX-2556 > Project: Phoenix > Issue Type: Bug > Reporter: James Taylor > Assignee: Maryann Xue > Fix For: 4.7.0 > > Attachments: PHOENIX-2556.patch, PHOENIX-2556_wip.patch > > > Subqueries with nested joins are only freeing some of the server-side hash cache memory, leading to essentially a kind of memory leak. > This problem occurs with the existing test case in SubqueryIT: > {code} > SELECT name from Join.CustomerTable > WHERE "customer_id" IN > (SELECT "customer_id" FROM Join.ItemTable i > JOIN Join.OrderTable o > ON o."item_id" = i."item_id" > WHERE i.name = 'T2' > OR quantity > > (SELECT avg(quantity) FROM Join.OrderTable q > WHERE o."item_id" = q."item_id")) > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)