[
https://issues.apache.org/jira/browse/PHOENIX-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715277#comment-14715277
]
James Taylor commented on PHOENIX-2207:
---------------------------------------
Thanks for the patch, [~samarthjain]. Now that Sunil has confirmed this fixes
the issue seen[1], I think the only remaining task is to add a unit test. I
think the easiest path would be to enable a ParallelIteratorFactory to be
injected into a query so we can wrap the TableResultIterator with a test one
that solely records and returns it's identifier so we can verify the sequence
of next calls. Something like this:
- Add a getter and setter for ParallelIteratorFactory on PhoenixConnection
- Use the QueryCompiler constructor that takes a here in PhoenixStatement for
ExecutableSelectStatement and pass through
connection.getParallelIteratorFactory():
{code}
QueryPlan plan = new QueryCompiler(stmt, select,
resolver).compile();
{code}
- Create a test derived from BaseConnectionlessTest that sets the
ParallelIteratorFactory on the connection with a dummy ResultIterator that
returns N rows, each with a simple Tuple that has a single column value with an
identifier for the ResultIterator.
- Run a simple SELECT * query that would use the RoundRobinIterator and asssert
the expected order based on the resultSet.getInt(1) value when you execute the
scan.
[1] http://s.apache.org/fp
> Load scanner caches in parallel when using stats and round robin iterator
> -------------------------------------------------------------------------
>
> Key: PHOENIX-2207
> URL: https://issues.apache.org/jira/browse/PHOENIX-2207
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Assignee: Samarth Jain
> Attachments: PHOENIX-2207.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
