[
https://issues.apache.org/jira/browse/PHOENIX-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083094#comment-15083094
]
Maryann Xue commented on PHOENIX-2556:
--------------------------------------
Good reminder, [~jamestaylor]. It was a subquery related bug in TxCheckPointIT,
but was because the MutationPlan for DELETE did not close the ResultIterator.
Non-subquery or non-join queries are fine since they don't have resources to be
closed anyway, but it was a problem for subqueries. I have also checked the
UpsertCompiler and it has a try block for closing the iterator so it should be
good.
The other two tests were good after I switched back to JDK 7, but they might
still be issues (probably similar to PHOENIX-2257). I'll open another JIRA to
track this.
> 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)
