[
https://issues.apache.org/jira/browse/PHOENIX-6340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272367#comment-17272367
]
ASF GitHub Bot commented on PHOENIX-6340:
-----------------------------------------
stoty commented on pull request #1112:
URL: https://github.com/apache/phoenix/pull/1112#issuecomment-767788988
There are two issues here.
The one that I am fixing is that RoundRobinResultIterator doesn't close
itself when every iterator 's last element is the last cached one, and will
re-initialize its iterator list on the next next() call.
The other, deeper problem is that even if those iterators are
re-initialized, they should still be at the their last element, and not start
returning their contents again.
Most of the the time this doesn't happen, I couldn't repro this in an IT,
and even sqlline calls almost the same methods in both modes, yet the bug
triggers only with BufferedRows.
So the second issue seems to be a timing/race issue.
The bug is old, but it was masked by ResultSet close() -ing itself at last
row. This was removed as this caused problem with many apps. This patch does
the same thing that ResultSet used to do, only one level lower.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Infinitely looping ResultSet.next()
> -----------------------------------
>
> Key: PHOENIX-6340
> URL: https://issues.apache.org/jira/browse/PHOENIX-6340
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 5.1.0
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Blocker
> Attachments: create_table.sql, make_csv.py
>
>
> Under certain conditions, ResultSet.next() will loop the results indefinitely.
> Unfortunately, I haven't been able to replicate this in a unit test.
> Steps for manual replication:
> 1. Download and run make_csv.py
> {noformat}
> python3 make_csv.py > data.csv
> {noformat}
> 2. Add the following to bin/hbase-site.xml, then do issue *mvn clean package*
> {noformat}
> <property>
> <name>hbase.client.scanner.caching</name>
> <value>100</value>
> </property>
> {noformat}
> 3. run *bin/phoenix_sandbox.py*
> 4. connect to sandbox with sqlline, create test table (see create_table.sql)
> 5. load the test data (data.csv) into the table
> {noformat}
> bin/psql.py -s -a ";" -t LARGE_TABLE localhost:<sandbox_port> /data.csv
> {noformat}
> 6. connect to sandbox with sqlline, run the following command
> {noformat}
> select * from large_table where id>100 and id<200 limit 300;
> {noformat}
> Instead of returning 99 rows, it will return 297 rows. If you omit the limit
> clause, the result will loop indefinitely.
> If you switch sqlline to incremental mode (*!set incremental true*), then the
> bug won't trigger, and the query will return 99 rows correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
