phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maryann Xue (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3394) Handle SequenceResolving through ConnectionQueryServices interface
Date Thu, 10 Nov 2016 22:53:58 GMT


Maryann Xue commented on PHOENIX-3394:

[~jamestaylor], [~lomoree], I just found out the cause for integration test failures. It turned
out that the check-in for this issue caused a memory leak issue. The SequenceManager put every
new sequence reference in an internal map regardless of validation success or failure and
we wanted to use one SequenceManager instance throughout the table/sequence resolving process.
A quick solution is to have a "reset()" method in SequenceManager, so if you guys think it's
reasonable I'll make the same change in Phoenix master and redo the fix check-in after syncing
with master.

> Handle SequenceResolving through ConnectionQueryServices interface
> ------------------------------------------------------------------
>                 Key: PHOENIX-3394
>                 URL:
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Eric Lomore
>            Assignee: Eric Lomore
> Tons of unit tests have this same stack trace. It appears that this call shouldn't reach
> {code}
> Caused by: java.lang.UnsupportedOperationException
> 	at org.apache.phoenix.query.ConnectionlessQueryServicesImpl.getTable(
> 	at org.apache.phoenix.query.DelegateConnectionQueryServices.getTable(
> 	at org.apache.phoenix.execute.MutationState.getHTable(
> 	at org.apache.phoenix.iterate.TableResultIterator.<init>(
> 	at org.apache.phoenix.iterate.DefaultTableResultIteratorFactory.newIterator(
> 	at org.apache.phoenix.iterate.ParallelIterators.submitWork(
> 	at org.apache.phoenix.iterate.BaseResultIterators.getIterators(
> 	... 71 more
> {code}

This message was sent by Atlassian JIRA

View raw message