[ 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)
|