[jira] [Updated] (PHOENIX-4830) order by primary key desc return wrong results
[
https://issues.apache.org/jira/browse/PHOENIX-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Cang updated PHOENIX-4830:
-
Attachment: PHOENIX-4830-4.x-HBase-1.3.006.patch
> order by primary key desc return wrong results
> --
>
> Key: PHOENIX-4830
> URL: https://issues.apache.org/jira/browse/PHOENIX-4830
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.0
> Environment: phoenix-4.14-hbase-1.2
>Reporter: JieChen
>Assignee: Xu Cang
>Priority: Major
> Attachments: PHOENIX-4830-4.x-HBase-1.3.001.patch,
> PHOENIX-4830-4.x-HBase-1.3.002.patch, PHOENIX-4830-4.x-HBase-1.3.003.patch,
> PHOENIX-4830-4.x-HBase-1.3.004.patch, PHOENIX-4830-4.x-HBase-1.3.005.patch,
> PHOENIX-4830-4.x-HBase-1.3.006.patch
>
>
> {code:java}
> 0: jdbc:phoenix:localhost> create table test(id bigint not null primary key,
> a bigint);
> No rows affected (1.242 seconds)
> 0: jdbc:phoenix:localhost> upsert into test values(1,11);
> 1 row affected (0.01 seconds)
> 0: jdbc:phoenix:localhost> upsert into test values(2,22);
> 1 row affected (0.007 seconds)
> 0: jdbc:phoenix:localhost> upsert into test values(3,33);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> select * from test;
> +-+-+
> | ID | A |
> +-+-+
> | 1 | 11 |
> | 2 | 22 |
> | 3 | 33 |
> +-+-+
> 3 rows selected (0.015 seconds)
> 0: jdbc:phoenix:localhost> select * from test order by id desc limit 2 offset
> 0;
> +-+-+
> | ID | A |
> +-+-+
> | 3 | 33 |
> | 2 | 22 |
> +-+-+
> 2 rows selected (0.018 seconds)
> 0: jdbc:phoenix:localhost> select * from test where id in (select id from
> test ) order by id desc limit 2 offset 0;
> +-+-+
> | ID | A |
> +-+-+
> | 2 | 22 |
> | 1 | 11 |
> +-+-+
> wrong results.
> {code}
> there may be some errors. ScanUtil.setupReverseScan code.
> then
> {code:java}
> 0: jdbc:phoenix:localhost> upsert into test values(4,33);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> upsert into test values(5,23);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> upsert into test values(6,23);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> upsert into test values(7,33);
> 1 row affected (0.006 seconds)
> {code}
> execute sql
> {code:java}
> select * from test where id in (select id from test where a=33) order by id
> desc;
> {code}
> throw exception
> {code:java}
> Error: org.apache.phoenix.exception.PhoenixIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException:
> TEST,,1533266754845.b8e521d4dc8e8b8f18c69cc7ef76973d.: The next hint must
> come after previous hint
> (prev=\x80\x00\x00\x00\x00\x00\x00\x07//LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0,
>
> next=\x80\x00\x00\x00\x00\x00\x00\x07//LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0,
>
> kv=\x80\x00\x00\x00\x00\x00\x00\x06/0:\x00\x00\x00\x00/1533266778944/Put/vlen=1/seqid=9)
> at org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:96)
> at org.apache.phoenix.util.ServerUtil.throwIOException(ServerUtil.java:62)
> at
> org.apache.phoenix.iterate.RegionScannerFactory$1.nextRaw(RegionScannerFactory.java:212)
> at
> org.apache.phoenix.coprocessor.HashJoinRegionScanner.nextRaw(HashJoinRegionScanner.java:264)
> at
> org.apache.phoenix.coprocessor.DelegateRegionScanner.nextRaw(DelegateRegionScanner.java:82)
> at
> org.apache.phoenix.coprocessor.DelegateRegionScanner.nextRaw(DelegateRegionScanner.java:82)
> at
> org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.nextRaw(BaseScannerRegionObserver.java:293)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:2541)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:33648)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2183)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:183)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:163)
> Caused by: java.lang.IllegalStateException: The next hint must come after
> previous hint
> (prev=\x80\x00\x00\x00\x00\x00\x00\x07//LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0,
>
> next=\x80\x00\x00\x00\x00\x00\x00\x07//LATEST_TIMESTAMP/Maximum/vlen=0/seqid=0,
>
> kv=\x80\x00\x00\x00\x00\x00\x00\x06/0:\x00\x00\x00\x00/1533266778944/Put/vlen=1/seqid=9)
> at
> org.apache.phoenix.filter.SkipScanFilter.setNextCellHint(SkipScanFilter.java:171)
> at
> org.apache.phoenix.filter.SkipScanFilter.filterKeyValue(SkipScanFilter.java:145)
> at
> org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.match(ScanQueryMatcher.java:427)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.ne
[jira] [Created] (PHOENIX-4861) While adding a view column make a single RPC to update the encoded column qualifier counter and remove the table from the cache of the physical table
Thomas D'Silva created PHOENIX-4861:
---
Summary: While adding a view column make a single RPC to update
the encoded column qualifier counter and remove the table from the cache of the
physical table
Key: PHOENIX-4861
URL: https://issues.apache.org/jira/browse/PHOENIX-4861
Project: Phoenix
Issue Type: Sub-task
Reporter: Thomas D'Silva
For tables that use column encoding when we add a column to a view we need to
update the encoded column qualifier counter on the base table. Currently we do
this in two rpcs:
{code}
// there should only be remote mutations if we are creating
a view that uses
// encoded column qualifiers (the remote mutations are to
update the encoded
// column qualifier counter on the parent table)
if (parentTable != null && tableType == PTableType.VIEW &&
parentTable
.getEncodingScheme() !=
QualifierEncodingScheme.NON_ENCODED_QUALIFIERS) {
response =
processRemoteRegionMutations(
PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES,
remoteMutations,
MetaDataProtos.MutationCode.UNABLE_TO_UPDATE_PARENT_TABLE);
clearParentTableFromCache(clientTimeStamp,
parentTable.getSchemaName() != null
? parentTable.getSchemaName().getBytes()
: ByteUtil.EMPTY_BYTE_ARRAY,
parentTable.getName().getBytes());
if (response != null) {
done.run(response);
return;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-3178) Row count incorrect for UPSERT SELECT when auto commit is false
[
https://issues.apache.org/jira/browse/PHOENIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swaroopa Kadam updated PHOENIX-3178:
Description:
To reproduce, use the following test:
{code:java}
@Test
public void testRowCountWithNoAutoCommitOnUpsertSelect() throws Exception {
Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
props.setProperty(QueryServices.MUTATE_BATCH_SIZE_ATTRIB,
Integer.toString(3));
props.setProperty(QueryServices.SCAN_CACHE_SIZE_ATTRIB,
Integer.toString(3));
props.setProperty(QueryServices.SCAN_RESULT_CHUNK_SIZE,
Integer.toString(3));
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.setAutoCommit(false);
conn.createStatement().execute("CREATE SEQUENCE keys");
String tableName = generateRandomString();
conn.createStatement().execute(
"CREATE TABLE " + tableName + " (pk INTEGER PRIMARY KEY, val
INTEGER)");
conn.createStatement().execute(
"UPSERT INTO " + tableName + " VALUES (NEXT VALUE FOR keys,1)");
conn.commit();
for (int i=0; i<6; i++) {
Statement stmt = conn.createStatement();
int upsertCount = stmt.executeUpdate(
"UPSERT INTO " + tableName + " SELECT NEXT VALUE FOR keys, val
FROM " + tableName);
conn.commit();
assertEquals((int)Math.pow(2, i), upsertCount);
}
conn.close();
}
{code}
was:
To reproduce, use the following test:
{code}
@Test
public void testRowCountWithNoAutoCommitOnUpsertSelect() throws Exception {
Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
props.setProperty(QueryServices.MUTATE_BATCH_SIZE_ATTRIB,
Integer.toString(3));
props.setProperty(QueryServices.SCAN_CACHE_SIZE_ATTRIB,
Integer.toString(3));
props.setProperty(QueryServices.SCAN_RESULT_CHUNK_SIZE,
Integer.toString(3));
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.setAutoCommit(false);
conn.createStatement().execute("CREATE SEQUENCE keys");
String tableName = generateRandomString();
conn.createStatement().execute(
"CREATE TABLE " + tableName + " (pk INTEGER PRIMARY KEY, val
INTEGER)");
conn.createStatement().execute(
"UPSERT INTO " + tableName + " VALUES (NEXT VALUE FOR keys,1)");
conn.commit();
for (int i=0; i<6; i++) {
Statement stmt = conn.createStatement();
int upsertCount = stmt.executeUpdate(
"UPSERT INTO " + tableName + " SELECT NEXT VALUE FOR keys, val
FROM " + tableName);
conn.commit();
assertEquals((int)Math.pow(2, i), upsertCount);
}
conn.close();
}
{code}
> Row count incorrect for UPSERT SELECT when auto commit is false
> ---
>
> Key: PHOENIX-3178
> URL: https://issues.apache.org/jira/browse/PHOENIX-3178
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Swaroopa Kadam
>Priority: Major
> Labels: newbie
> Fix For: 4.15.0
>
>
> To reproduce, use the following test:
> {code:java}
> @Test
> public void testRowCountWithNoAutoCommitOnUpsertSelect() throws Exception
> {
> Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
> props.setProperty(QueryServices.MUTATE_BATCH_SIZE_ATTRIB,
> Integer.toString(3));
> props.setProperty(QueryServices.SCAN_CACHE_SIZE_ATTRIB,
> Integer.toString(3));
> props.setProperty(QueryServices.SCAN_RESULT_CHUNK_SIZE,
> Integer.toString(3));
> Connection conn = DriverManager.getConnection(getUrl(), props);
> conn.setAutoCommit(false);
> conn.createStatement().execute("CREATE SEQUENCE keys");
> String tableName = generateRandomString();
> conn.createStatement().execute(
> "CREATE TABLE " + tableName + " (pk INTEGER PRIMARY KEY, val
> INTEGER)");
> conn.createStatement().execute(
> "UPSERT INTO " + tableName + " VALUES (NEXT VALUE FOR keys,1)");
> conn.commit();
> for (int i=0; i<6; i++) {
> Statement stmt = conn.createStatement();
> int upsertCount = stmt.executeUpdate(
> "UPSERT INTO " + tableName + " SELECT NEXT VALUE FOR keys,
> val FROM " + tableName);
> conn.commit();
> assertEquals((int)Math.pow(2, i), upsertCount);
> }
> conn.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4798) Update encoded col qualifiers on the base table correctly
[ https://issues.apache.org/jira/browse/PHOENIX-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4798: Attachment: PHOENIX-4798-4.x-HBase-1.3-v3.patch > Update encoded col qualifiers on the base table correctly > - > > Key: PHOENIX-4798 > URL: https://issues.apache.org/jira/browse/PHOENIX-4798 > Project: Phoenix > Issue Type: Sub-task >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva >Priority: Major > Attachments: PHOENIX-4798-4.x-HBase-1.3-v2.patch, > PHOENIX-4798-4.x-HBase-1.3-v3.patch, PHOENIX-4798-4.x-HBase-1.3.patch > > > For tables that use column qualifier encoding, when a column is added or view > created we update the encoded column qualifier on the base table and > increment its sequence number. > Add a check to see if the base table is at the expected sequence number and > fail if it is not with a CONCURRENT_TABLE_MUTATION -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4667) Create index on a view should return error if any of the REPLICATION_SCOPE/TTL/KEEP_DELETED_CELLS attributes are set
[ https://issues.apache.org/jira/browse/PHOENIX-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni resolved PHOENIX-4667. --- Resolution: Fixed This issue will be fixed by the changes required for PHOENIX-3955, hence marking this as a duplicate. > Create index on a view should return error if any of the > REPLICATION_SCOPE/TTL/KEEP_DELETED_CELLS attributes are set > > > Key: PHOENIX-4667 > URL: https://issues.apache.org/jira/browse/PHOENIX-4667 > Project: Phoenix > Issue Type: Bug >Reporter: Akshita Malhotra >Assignee: Chinmay Kulkarni >Priority: Minor > Labels: index, schema > Fix For: 4.15.0 > > > As the physical view index table is shared, create index on a view statements > should return error if the user tries to set attributes which affect the > physical table such as REPLICATION_SCOPE, TTL, KEEP_DELETED_CELLS etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (PHOENIX-4667) Create index on a view should return error if any of the REPLICATION_SCOPE/TTL/KEEP_DELETED_CELLS attributes are set
[ https://issues.apache.org/jira/browse/PHOENIX-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni reassigned PHOENIX-4667: - Assignee: Chinmay Kulkarni > Create index on a view should return error if any of the > REPLICATION_SCOPE/TTL/KEEP_DELETED_CELLS attributes are set > > > Key: PHOENIX-4667 > URL: https://issues.apache.org/jira/browse/PHOENIX-4667 > Project: Phoenix > Issue Type: Bug >Reporter: Akshita Malhotra >Assignee: Chinmay Kulkarni >Priority: Minor > Labels: index, schema > Fix For: 4.15.0 > > > As the physical view index table is shared, create index on a view statements > should return error if the user tries to set attributes which affect the > physical table such as REPLICATION_SCOPE, TTL, KEEP_DELETED_CELLS etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (PHOENIX-3178) Row count incorrect for UPSERT SELECT when auto commit is false
[
https://issues.apache.org/jira/browse/PHOENIX-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva reassigned PHOENIX-3178:
---
Assignee: Swaroopa Kadam
> Row count incorrect for UPSERT SELECT when auto commit is false
> ---
>
> Key: PHOENIX-3178
> URL: https://issues.apache.org/jira/browse/PHOENIX-3178
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Swaroopa Kadam
>Priority: Major
> Labels: newbie
> Fix For: 4.15.0
>
>
> To reproduce, use the following test:
> {code}
> @Test
> public void testRowCountWithNoAutoCommitOnUpsertSelect() throws Exception
> {
> Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
> props.setProperty(QueryServices.MUTATE_BATCH_SIZE_ATTRIB,
> Integer.toString(3));
> props.setProperty(QueryServices.SCAN_CACHE_SIZE_ATTRIB,
> Integer.toString(3));
> props.setProperty(QueryServices.SCAN_RESULT_CHUNK_SIZE,
> Integer.toString(3));
> Connection conn = DriverManager.getConnection(getUrl(), props);
> conn.setAutoCommit(false);
> conn.createStatement().execute("CREATE SEQUENCE keys");
> String tableName = generateRandomString();
> conn.createStatement().execute(
> "CREATE TABLE " + tableName + " (pk INTEGER PRIMARY KEY, val
> INTEGER)");
> conn.createStatement().execute(
> "UPSERT INTO " + tableName + " VALUES (NEXT VALUE FOR keys,1)");
> conn.commit();
> for (int i=0; i<6; i++) {
> Statement stmt = conn.createStatement();
> int upsertCount = stmt.executeUpdate(
> "UPSERT INTO " + tableName + " SELECT NEXT VALUE FOR keys,
> val FROM " + tableName);
> conn.commit();
> assertEquals((int)Math.pow(2, i), upsertCount);
> }
> conn.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (PHOENIX-4755) Provide an option to plugin custom avatica server config in PQS
[
https://issues.apache.org/jira/browse/PHOENIX-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karan Mehta reassigned PHOENIX-4755:
Labels: queryserver (was: )
Assignee: Karan Mehta
Fix Version/s: 5.1.0
4.15.0
Pushed it to 4.x-HBase-1.2, 4.x-HBase-1.3, 4.x-HBase-1.4 and master branches.
Thanks [~elserj] for the review.
> Provide an option to plugin custom avatica server config in PQS
> ---
>
> Key: PHOENIX-4755
> URL: https://issues.apache.org/jira/browse/PHOENIX-4755
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Labels: queryserver
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4755.001.diff, PHOENIX-4755.002.diff,
> PHOENIX-4755.003.diff, PHOENIX-4755.4.x-HBase-1.4.patch
>
>
> CALCITE-2294 Allow customization for {{AvaticaServerConfiguration}} for
> plugging new authentication mechanisms
> Add a new Phoenix level property and provide resolve the class using
> {{InstanceResolver}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4859) Using local index in where statement for join (only rhs table) query fails
[
https://issues.apache.org/jira/browse/PHOENIX-4859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-4859.
-
Resolution: Invalid
This is against an HDP release, not an Apache release.
More work needs to be done in-house at Hortonworks first.
> Using local index in where statement for join (only rhs table) query fails
> --
>
> Key: PHOENIX-4859
> URL: https://issues.apache.org/jira/browse/PHOENIX-4859
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.7.0, 5.0.0
>Reporter: Subrat Mishra
>Priority: Major
>
> Consider a simple scenario:
> {code:java}
> CREATE TABLE cust_data (customer_id integer primary key, postal_code varchar,
> country_code varchar);
> UPSERT INTO cust_data values(1,'560103','IN');
> CREATE LOCAL INDEX ZIP_INDEX ON cust_data(postal_code);
> SELECT * from cust_data c1, cust_data c2 where c1.customer_id=c2.customer_id
> and c2.postal_code='560103'; {code}
> Query fails with an exception:
> (For version- 4.7.0)
>
> {code:java}
> Error: ERROR 504 (42703): Undefined column. columnName=0:COUNTRY_CODE
> (state=42703,code=504)
> org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703):
> Undefined column. columnName=0:COUNTRY_CODE
> at org.apache.phoenix.schema.PTableImpl.getColumn(PTableImpl.java:665)
> at
> org.apache.phoenix.compile.FromCompiler$MultiTableColumnResolver.resolveColumn(FromCompiler.java:874)
>
> at
> org.apache.phoenix.compile.FromCompiler$ProjectedTableColumnResolver.resolveColumn(FromCompiler.java:941)
>
> at
> org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:239)
>
> at
> org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
>
> at
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:557)
>
> at
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:247)
>
> at
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:294)
>
> at
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:197)
>
> at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:154)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:404)
>
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:378)
>
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:271)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:266)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:265)
>
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1444)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292) {code}
> (For version- 5.0.0)
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.phoenix.schema.LocalIndexDataColumnRef.(LocalIndexDataColumnRef.java:40)
> at
> org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:221)
> at
> org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:389)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:561)
> at
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:320)
> at
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:228)
> at
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:191)
> at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:153)
> at
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:190)
> at
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:112)
> at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:98)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine
[jira] [Assigned] (PHOENIX-4860) CursorUtil Needs to Use a ConcurrentHashMap rather than HashMap
[ https://issues.apache.org/jira/browse/PHOENIX-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal reassigned PHOENIX-4860: -- Assignee: Jack Steenkamp > CursorUtil Needs to Use a ConcurrentHashMap rather than HashMap > --- > > Key: PHOENIX-4860 > URL: https://issues.apache.org/jira/browse/PHOENIX-4860 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0, 4.13.1, 5.0.0 >Reporter: Jack Steenkamp >Assignee: Jack Steenkamp >Priority: Major > Attachments: CursorUtil.patch > > > in very rare cases, when dealing with Apache Phoenix Cursors, the following > NullPointerException is encountered: > java.lang.NullPointerException: null > at org.apache.phoenix.util.CursorUtil.updateCursor(CursorUtil.java:179) > at > org.apache.phoenix.iterate.CursorResultIterator.next(CursorResultIterator.java:46) > at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:779) > (This is for 4.13.1 - but seems that > org.apache.phoenix.util.CursorUtil has not changed, at the time of writing, > since first being introduced as part of PHOENIX-3572). > Upon closer inspection it would seem that on line 124 of CursorUtil, a > HashMap is used to keep state which is then exposed via a number of > static methods, which, one has to assume, can be accessed by many > different threads. Using a plain old HashMap in cases like these can cause > issues. > The mapCursorIDQuery member should be a ConcurrentHashMap instead? That > should tighten up the class and prevent any potential inconsistencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4860) CursorUtil Needs to Use a ConcurrentHashMap rather than HashMap
Jack Steenkamp created PHOENIX-4860: --- Summary: CursorUtil Needs to Use a ConcurrentHashMap rather than HashMap Key: PHOENIX-4860 URL: https://issues.apache.org/jira/browse/PHOENIX-4860 Project: Phoenix Issue Type: Bug Affects Versions: 5.0.0, 4.13.1, 4.14.0 Reporter: Jack Steenkamp Attachments: CursorUtil.patch in very rare cases, when dealing with Apache Phoenix Cursors, the following NullPointerException is encountered: java.lang.NullPointerException: null at org.apache.phoenix.util.CursorUtil.updateCursor(CursorUtil.java:179) at org.apache.phoenix.iterate.CursorResultIterator.next(CursorResultIterator.java:46) at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:779) (This is for 4.13.1 - but seems that org.apache.phoenix.util.CursorUtil has not changed, at the time of writing, since first being introduced as part of PHOENIX-3572). Upon closer inspection it would seem that on line 124 of CursorUtil, a HashMap is used to keep state which is then exposed via a number of static methods, which, one has to assume, can be accessed by many different threads. Using a plain old HashMap in cases like these can cause issues. The mapCursorIDQuery member should be a ConcurrentHashMap instead? That should tighten up the class and prevent any potential inconsistencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4859) Using local index in where statement for join (only rhs table) query fails
Subrat Mishra created PHOENIX-4859:
--
Summary: Using local index in where statement for join (only rhs
table) query fails
Key: PHOENIX-4859
URL: https://issues.apache.org/jira/browse/PHOENIX-4859
Project: Phoenix
Issue Type: Bug
Affects Versions: 5.0.0, 4.7.0
Reporter: Subrat Mishra
Consider a simple scenario:
{code:java}
CREATE TABLE cust_data (customer_id integer primary key, postal_code varchar,
country_code varchar);
UPSERT INTO cust_data values(1,'560103','IN');
CREATE LOCAL INDEX ZIP_INDEX ON cust_data(postal_code);
SELECT * from cust_data c1, cust_data c2 where c1.customer_id=c2.customer_id
and c2.postal_code='560103'; {code}
Query fails with an exception:
(For version- 4.7.0)
{code:java}
Error: ERROR 504 (42703): Undefined column. columnName=0:COUNTRY_CODE
(state=42703,code=504)
org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): Undefined
column. columnName=0:COUNTRY_CODE
at org.apache.phoenix.schema.PTableImpl.getColumn(PTableImpl.java:665)
at
org.apache.phoenix.compile.FromCompiler$MultiTableColumnResolver.resolveColumn(FromCompiler.java:874)
at
org.apache.phoenix.compile.FromCompiler$ProjectedTableColumnResolver.resolveColumn(FromCompiler.java:941)
at
org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:239)
at
org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:393)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:557)
at
org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:247)
at
org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:294)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:197)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:154)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:404)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:378)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:271)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:266)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:265)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1444)
at sqlline.Commands.execute(Commands.java:822)
at sqlline.Commands.sql(Commands.java:732)
at sqlline.SqlLine.dispatch(SqlLine.java:808)
at sqlline.SqlLine.begin(SqlLine.java:681)
at sqlline.SqlLine.start(SqlLine.java:398)
at sqlline.SqlLine.main(SqlLine.java:292) {code}
(For version- 5.0.0)
{code:java}
java.lang.NullPointerException
at
org.apache.phoenix.schema.LocalIndexDataColumnRef.(LocalIndexDataColumnRef.java:40)
at
org.apache.phoenix.compile.ProjectionCompiler.projectAllIndexColumns(ProjectionCompiler.java:221)
at
org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:389)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:561)
at
org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:320)
at
org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:228)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:191)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:153)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:190)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:112)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:98)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
at sqlline.Commands.execute(Commands.java:822)
at sqlline.Commands.sql(Commands.java:732)
at sqlline.SqlLine.dispatch(SqlLine.java:813)
at sqlline.SqlLine.begin(SqlLine.java:686)
at sqlline.SqlLine.start(SqlLine.java:398)
at sqlline.SqlLine.main(SqlLine.java:291){code}
Interestingly if we change c2.postal_code to c1.postal_code in where clause
like shown below then the query runs fine.
{code:java}
SELECT * from cust_data c1, cust_data c2 where c1.customer_id=c2.customer_id
and c1.postal_code='560103'; {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
