[ 
https://issues.apache.org/jira/browse/PHOENIX-6340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth updated PHOENIX-6340:
---------------------------------
    Description: 
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.


  was:
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. 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}

2. run *bin/phoenix_sandbox.py*

3. connect to sandbox with sqlline, create test table (see create_table.sql)

4. load the test data (data.csv) into the table

{noformat}
bin/psql.py -s -a ";"  -t LARGE_TABLE localhost:<sandbox_port>  /data.csv
{noformat}

5. 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.



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

Reply via email to