You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Mehdi Salarkia (JIRA)" <ji...@apache.org> on 2019/06/27 18:26:00 UTC
[jira] [Comment Edited] (PHOENIX-5104) PHOENIX-3547 breaks client
backwards compatability
[ https://issues.apache.org/jira/browse/PHOENIX-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874406#comment-16874406 ]
Mehdi Salarkia edited comment on PHOENIX-5104 at 6/27/19 6:25 PM:
------------------------------------------------------------------
Hi [~lhofhansl]
> [~m2je], ping :)
Pong :)
> Start a Phoenix-Hbase server on version 4.15, then use a 4.15 client to create the table, then use a 4.14 client to run the explain. I think that wasn't covered in your scenario.
We actually saw this issue once in our environment which was solved after bouncing Phoenix Query server.
My understanding is there was a stale/corrupt cached in PQS that some how caused this problem, unfortunately I haven't had enough time to dig deeper and find out how that happened. I think my tests scenario could not catch this case as I started off fresh. Perhaps we could suggest this workaround if anybody runs into this issue and if after bouncing the PQS hosts they still experience the same issue (which hasn't happen in our cluster anymore) we extend this investigation?
> PHOENIX-5103 is probably the same issue.
Not sure if it is related, It seems like the table `SYSTEM:CHILD_LINK` was not build as part of startup upgrade? Am I missing something?
was (Author: m2je):
Hi [~lhofhansl]
>[~m2je], ping :)
Pong :)
> Start a Phoenix-Hbase server on version 4.15, then use a 4.15 client to create the table, then use a 4.14 client to run the explain. I think that wasn't covered in your scenario.
We actually saw this issue once in our environment which was solved after bouncing Phoenix Query server.
My understanding is there was a stale/corrupt cached in PQS that some how caused this problem, unfortunately I haven't had enough time to dig deeper and find out how that happened. I think my tests scenario could not catch this case as I started off fresh. Perhaps we could suggest this workaround if anybody runs into this issue and if after bouncing the PQS hosts they still experience the same issue (which hasn't happen in our cluster anymore) we extend this investigation?
>PHOENIX-5103 is probably the same issue.
Not sure if it is related, It seems like the table `SYSTEM:CHILD_LINK` was not build as part of startup upgrade? Am I missing something?
> PHOENIX-3547 breaks client backwards compatability
> --------------------------------------------------
>
> Key: PHOENIX-5104
> URL: https://issues.apache.org/jira/browse/PHOENIX-5104
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.0
> Reporter: Lars Hofhansl
> Assignee: Mehdi Salarkia
> Priority: Blocker
> Labels: SFDC
> Fix For: 4.15.0
>
>
> Scenario:
> * New 4.15 client
> ** {{create table ns1.test (pk1 integer not null, pk2 integer not null, pk3 integer not null, v1 float, v2 float, v3 integer CONSTRAINT pk PRIMARY KEY (pk1, pk2, pk3));}}
> ** {{create local index l1 on ns1.test(v1);}}
> * Old 4.14.x client
> ** {{explain select count\(*) from test t1 where t1.v1 < 0.000001;}}
> Result:
> {code}
> 0: jdbc:phoenix:localhost> explain select count(*) from ns1.test t1 where t1.v1 < 0.000001;
> Error: ERROR 201 (22000): Illegal data. Expected length of at least 8 bytes, but had 2 (state=22000,code=201)
> java.sql.SQLException: ERROR 201 (22000): Illegal data. Expected length of at least 8 bytes, but had 2
> at org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:494)
> at org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150)
> at org.apache.phoenix.schema.types.PDataType.checkForSufficientLength(PDataType.java:290)
> at org.apache.phoenix.schema.types.PLong$LongCodec.decodeLong(PLong.java:256)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:115)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:31)
> at org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:994)
> at org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1035)
> at org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1031)
> at org.apache.phoenix.iterate.ExplainTable.appendPKColumnValue(ExplainTable.java:207)
> at org.apache.phoenix.iterate.ExplainTable.appendScanRow(ExplainTable.java:282)
> at org.apache.phoenix.iterate.ExplainTable.appendKeyRanges(ExplainTable.java:297)
> at org.apache.phoenix.iterate.ExplainTable.explain(ExplainTable.java:127)
> at org.apache.phoenix.iterate.BaseResultIterators.explain(BaseResultIterators.java:1544)
> at org.apache.phoenix.iterate.ConcatResultIterator.explain(ConcatResultIterator.java:92)
> at org.apache.phoenix.iterate.BaseGroupedAggregatingResultIterator.explain(BaseGroupedAggregatingResultIterator.java:103)
> at org.apache.phoenix.execute.BaseQueryPlan.getPlanSteps(BaseQueryPlan.java:524)
> at org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:372)
> at org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:217)
> at org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:212)
> at org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:207)
> at org.apache.phoenix.execute.BaseQueryPlan.getExplainPlan(BaseQueryPlan.java:516)
> at org.apache.phoenix.jdbc.PhoenixStatement$ExecutableExplainStatement.compilePlan(PhoenixStatement.java:603)
> at org.apache.phoenix.jdbc.PhoenixStatement$ExecutableExplainStatement.compilePlan(PhoenixStatement.java:575)
> at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:302)
> 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)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)