You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Jack Steenkamp (JIRA)" <ji...@apache.org> on 2018/12/18 08:59:00 UTC
[jira] [Created] (PHOENIX-5072) Cursor Query Loops Eternally with
Local Index, Returns Fine Without It
Jack Steenkamp created PHOENIX-5072:
---------------------------------------
Summary: Cursor Query Loops Eternally with Local Index, Returns Fine Without It
Key: PHOENIX-5072
URL: https://issues.apache.org/jira/browse/PHOENIX-5072
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.14.1
Reporter: Jack Steenkamp
Attachments: PhoenixEternalCursorTest.java
I have come across a case where a particular cursor query would carry on looping forever if executed when a local index is present. If however, I execute the same query without a local index on the table, then it works as expected.
You can reproduce this by executing the attached standalone test case. You only need to modify the JDBC_URL constant (by default it tries to connect to localhost) and then you compare the outputs between hving CREATE_INDEX = true or CREATE_INDEX = false.
Here is an example of the output:
*1) Connect to an environment and create a simple table:*
{code:java}
Connecting To : jdbc:phoenix:localhost:63214{code}
{code:java}
CREATE TABLE IF NOT EXISTS SOME_NUMBERS
(
ID VARCHAR NOT NULL,
NAME VARCHAR ,
ANOTHER_VALUE VARCHAR ,
TRANSACTION_TIME TIMESTAMP ,
CONSTRAINT pk PRIMARY KEY(ID)
) IMMUTABLE_STORAGE_SCHEME=ONE_CELL_PER_COLUMN,
UPDATE_CACHE_FREQUENCY=900000,
COLUMN_ENCODED_BYTES=NONE,
IMMUTABLE_ROWS=true{code}
*2) Optionally create a local index:*
If you want to reproduce the failure, create an index:
{code:java}
CREATE LOCAL INDEX index_01 ON SOME_NUMBERS(NAME, TRANSACTION_TIME DESC) INCLUDE(ANOTHER_VALUE){code}
Otherwise, skip this.
*3) Insert a number of objects and verify their count*
{code:java}
System.out.println("\nInserting Some Items");
DecimalFormat dmf = new DecimalFormat("0000");
final String prefix = "ReferenceData.Country/";
for (int i = 0; i < 5; i++)
{
for (int j = 0; j < 2; j++)
{
PreparedStatement prstmt = conn.prepareStatement("UPSERT INTO SOME_NUMBERS VALUES(?,?,?,?)");
prstmt.setString(1,UUID.randomUUID().toString());
prstmt.setString(2,prefix + dmf.format(i));
prstmt.setString(3,UUID.randomUUID().toString());
prstmt.setTimestamp(4, new Timestamp(System.currentTimeMillis()));
prstmt.execute();
conn.commit();3) Insert a number of objects and verify their count_
prstmt.close();
}
}{code}
Verify the count afterwards with:
{code:java}
SELECT COUNT(1) AS TOTAL_ITEMS FROM SOME_NUMBERS {code}
*5) Run a Cursor Query*
Run a cursor using the standard sequence of commands as appropriate:
{code:java}
DECLARE MyCursor CURSOR FOR SELECT NAME,ANOTHER_VALUE FROM SOME_NUMBERS where NAME like 'ReferenceData.Country/%' ORDER BY TRANSACTION_TIME DESC{code}
{code:java}
OPEN MyCursor{code}
{code:java}
FETCH NEXT 10 ROWS FROM MyCursor{code}
* Without an index it will return the correct number of rows
{code:java}
Cursor SQL : DECLARE MyCursor CURSOR FOR SELECT NAME,ANOTHER_VALUE FROM SOME_NUMBERS where NAME like 'ReferenceData.Country/%' ORDER BY TRANSACTION_TIME DESC
CLOSING THE CURSOR
Result : 0
ITEMS returned by count : 10 | Items Returned by Cursor : 10
ALL GOOD - No Exception{code}
* With an index it will return far more than the number of rows (it appears to be erroneously looping for ever - hence the test-case terminates it).
{code:java}
Cursor SQL : DECLARE MyCursor CURSOR FOR SELECT NAME,ANOTHER_VALUE FROM SOME_NUMBERS where NAME like 'ReferenceData.Country/%' ORDER BY TRANSACTION_TIME DESC
ITEMS returned by count : 10 | Items Returned by Cursor : 40
Aborting the Cursor, as it is more than the count!
Exception in thread "main" java.lang.RuntimeException: The cursor returned a different number of rows from the count !! {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)