[jira] [Commented] (PHOENIX-6604) Index not used for wildcard topN query on salted table
[
https://issues.apache.org/jira/browse/PHOENIX-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448966#comment-17448966
]
Lars Hofhansl commented on PHOENIX-6604:
Actually attached patch fixes it for me. Should be safe, but not 100% sure
about side effects.
> Index not used for wildcard topN query on salted table
> --
>
> Key: PHOENIX-6604
> URL: https://issues.apache.org/jira/browse/PHOENIX-6604
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.1.2
>Reporter: Lars Hofhansl
>Priority: Major
> Fix For: 5.1.3
>
> Attachments: 6604.5.1.3
>
>
> Just randomly came across this, playing with TPCH data.
> {code:java}
> CREATE TABLE lineitem (
> orderkey bigint not null,
> partkey bigint,
> suppkey bigint,
> linenumber integer not null,
> quantity double,
> extendedprice double,
> discount double,
> tax double,
> returnflag varchar(1),
> linestatus varchar(1),
> shipdate date,
> commitdate date,
> receiptdate date,
> shipinstruct varchar(25),
> shipmode varchar(10),
> comment varchar(44)
> constraint pk primary key(orderkey, linenumber))
> IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
> Now:
> {code:java}
> > explain select * from lineitem order by shipdate limit 1;
> +---+
> | PLAN
> |
> +---+
> | CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
> OVER LI |
> | SERVER TOP 1 ROW SORTED BY [SHIPDATE]
> |
> | CLIENT MERGE SORT
> |
> | CLIENT LIMIT 1
> |
> +---+
> 4 rows selected (6.525 seconds)
> -- SAME COLUMNS!
> > explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> > EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> > RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by
> > shipdate limit 1;
> +---+
> |
> |
> +---+
> | CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
> |
> | SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
> 0.DISCOUNT, |
> | SERVER FILTER BY FIRST KEY ONLY
> |
> | SERVER 1 ROW LIMIT
> |
> | CLIENT MERGE SORT
> |
> | CLIENT 1 ROW LIMIT
> |
> +---+
> 6 rows selected (2.736 seconds){code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (PHOENIX-6604) Index not used for wildcard topN query on salted table
[
https://issues.apache.org/jira/browse/PHOENIX-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448958#comment-17448958
]
Lars Hofhansl commented on PHOENIX-6604:
The same happens with a fully covered global index.
[~kozdemir] , FYI.
> Index not used for wildcard topN query on salted table
> --
>
> Key: PHOENIX-6604
> URL: https://issues.apache.org/jira/browse/PHOENIX-6604
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.1.2
>Reporter: Lars Hofhansl
>Priority: Major
> Fix For: 5.1.3
>
>
> Just randomly came across this, playing with TPCH data.
> {code:java}
> CREATE TABLE lineitem (
> orderkey bigint not null,
> partkey bigint,
> suppkey bigint,
> linenumber integer not null,
> quantity double,
> extendedprice double,
> discount double,
> tax double,
> returnflag varchar(1),
> linestatus varchar(1),
> shipdate date,
> commitdate date,
> receiptdate date,
> shipinstruct varchar(25),
> shipmode varchar(10),
> comment varchar(44)
> constraint pk primary key(orderkey, linenumber))
> IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
> Now:
> {code:java}
> > explain select * from lineitem order by shipdate limit 1;
> +---+
> | PLAN
> |
> +---+
> | CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
> OVER LI |
> | SERVER TOP 1 ROW SORTED BY [SHIPDATE]
> |
> | CLIENT MERGE SORT
> |
> | CLIENT LIMIT 1
> |
> +---+
> 4 rows selected (6.525 seconds)
> -- SAME COLUMNS!
> > explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> > EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> > RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by
> > shipdate limit 1;
> +---+
> |
> |
> +---+
> | CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
> |
> | SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
> 0.DISCOUNT, |
> | SERVER FILTER BY FIRST KEY ONLY
> |
> | SERVER 1 ROW LIMIT
> |
> | CLIENT MERGE SORT
> |
> | CLIENT 1 ROW LIMIT
> |
> +---+
> 6 rows selected (2.736 seconds){code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (PHOENIX-6604) Local index not used for wildcard topN query on salted table
[
https://issues.apache.org/jira/browse/PHOENIX-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448953#comment-17448953
]
Lars Hofhansl commented on PHOENIX-6604:
I likely won't have time to track it down. Just leaving it here.
Local indexes are especially to allow for cheap sorting with an uncovered (i.e.
small) index.
{{SELECT *}} fails with it attempts to rewrite the query, with an unknown
column called: {{L_SHIPDATE.:_SALT}}
> Local index not used for wildcard topN query on salted table
>
>
> Key: PHOENIX-6604
> URL: https://issues.apache.org/jira/browse/PHOENIX-6604
> Project: Phoenix
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Priority: Major
> Fix For: 5.1.3
>
>
> Just randomly came across this, playing with TPCH data.
> {code:java}
> CREATE TABLE lineitem (
> orderkey bigint not null,
> partkey bigint,
> suppkey bigint,
> linenumber integer not null,
> quantity double,
> extendedprice double,
> discount double,
> tax double,
> returnflag varchar(1),
> linestatus varchar(1),
> shipdate date,
> commitdate date,
> receiptdate date,
> shipinstruct varchar(25),
> shipmode varchar(10),
> comment varchar(44)
> constraint pk primary key(orderkey, linenumber))
> DATA_BLOCK_ENCODING='ROW_INDEX_V1', COMPRESSION='ZSTD', DISABLE_WAL=true,
> IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
> Now:
> {code:java}
> > explain select * from lineitem order by shipdate limit 1;
> +---+
> | PLAN
> |
> +---+
> | CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
> OVER LI |
> | SERVER TOP 1 ROW SORTED BY [SHIPDATE]
> |
> | CLIENT MERGE SORT
> |
> | CLIENT LIMIT 1
> |
> +---+
> 4 rows selected (6.525 seconds)
> -- SAME COLUMNS!
> > explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> > EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> > RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by
> > shipdate limit 1;
> +---+
> |
> |
> +---+
> | CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
> |
> | SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
> 0.DISCOUNT, |
> | SERVER FILTER BY FIRST KEY ONLY
> |
> | SERVER 1 ROW LIMIT
> |
> | CLIENT MERGE SORT
> |
> | CLIENT 1 ROW LIMIT
> |
> +---+
> 6 rows selected (2.736 seconds){code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (PHOENIX-6603) Create SYSTEM.TRANSFORM table
[ https://issues.apache.org/jira/browse/PHOENIX-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448819#comment-17448819 ] ASF GitHub Bot commented on PHOENIX-6603: - gokceni opened a new pull request #1360: URL: https://github.com/apache/phoenix/pull/1360 Co-authored-by: Gokcen Iskender -- 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. To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create SYSTEM.TRANSFORM table > - > > Key: PHOENIX-6603 > URL: https://issues.apache.org/jira/browse/PHOENIX-6603 > Project: Phoenix > Issue Type: Sub-task >Reporter: Gokcen Iskender >Priority: Major > > SYSTEM.TRANSFORM is a table for bookkeeping the transform process -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [phoenix] gokceni opened a new pull request #1360: PHOENIX-6603: Add SYSTEM.TRANSFORM table (#656)
gokceni opened a new pull request #1360: URL: https://github.com/apache/phoenix/pull/1360 Co-authored-by: Gokcen Iskender -- 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. To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (PHOENIX-6603) Create SYSTEM.TRANSFORM table
[ https://issues.apache.org/jira/browse/PHOENIX-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448817#comment-17448817 ] ASF GitHub Bot commented on PHOENIX-6603: - gokceni commented on pull request #1359: URL: https://github.com/apache/phoenix/pull/1359#issuecomment-978223709 @gjacoby126 -- 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. To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create SYSTEM.TRANSFORM table > - > > Key: PHOENIX-6603 > URL: https://issues.apache.org/jira/browse/PHOENIX-6603 > Project: Phoenix > Issue Type: Sub-task >Reporter: Gokcen Iskender >Priority: Major > > SYSTEM.TRANSFORM is a table for bookkeeping the transform process -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (PHOENIX-6603) Create SYSTEM.TRANSFORM table
[ https://issues.apache.org/jira/browse/PHOENIX-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448816#comment-17448816 ] ASF GitHub Bot commented on PHOENIX-6603: - gokceni opened a new pull request #1359: URL: https://github.com/apache/phoenix/pull/1359 Co-authored-by: Gokcen Iskender -- 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. To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create SYSTEM.TRANSFORM table > - > > Key: PHOENIX-6603 > URL: https://issues.apache.org/jira/browse/PHOENIX-6603 > Project: Phoenix > Issue Type: Sub-task >Reporter: Gokcen Iskender >Priority: Major > > SYSTEM.TRANSFORM is a table for bookkeeping the transform process -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [phoenix] gokceni commented on pull request #1359: PHOENIX-6603: Add SYSTEM.TRANSFORM table (#656)
gokceni commented on pull request #1359: URL: https://github.com/apache/phoenix/pull/1359#issuecomment-978223709 @gjacoby126 -- 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. To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [phoenix] gokceni opened a new pull request #1359: PHOENIX-6603: Add SYSTEM.TRANSFORM table (#656)
gokceni opened a new pull request #1359: URL: https://github.com/apache/phoenix/pull/1359 Co-authored-by: Gokcen Iskender -- 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. To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (PHOENIX-6602) NullPointerException when send ExectuteRequest via protobuf with no parameters
[
https://issues.apache.org/jira/browse/PHOENIX-6602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448557#comment-17448557
]
Istvan Toth commented on PHOENIX-6602:
--
Ah, I missed the Protobuf line in the stack trace.
I assumed that you are using JSON because I saw a json format snippet above.
This is how parameters are handled in the python code:
https://github.com/apache/phoenix-queryserver/blob/07c006cf17d67437ad02e8cf7899ca274395d76e/python-phoenixdb/phoenixdb/avatica/client.py#L521
> NullPointerException when send ExectuteRequest via protobuf with no parameters
> --
>
> Key: PHOENIX-6602
> URL: https://issues.apache.org/jira/browse/PHOENIX-6602
> Project: Phoenix
> Issue Type: Bug
> Components: queryserver
>Affects Versions: queryserver-6.0.0
> Environment:
>Reporter: Aleksey Stavrov
>Priority: Major
>
> ExecuteRequest has following format:
> {noformat}
> message ExecuteRequest {
> StatementHandle statementHandle = 1;
> repeated TypedValue parameter_values = 2;
> uint64 deprecated_first_frame_max_size = 3;
> bool has_parameter_values = 4;
> int32 first_frame_max_size = 5;
> }
> {noformat}
> When i try to set *_has_parameter_values_* to _*false*_ and set 0 parameters
> then i get error:
> {noformat}
> 'protocol' => {
> 'severity' => 0,
> 'exceptions' => [
> 'java.lang.NullPointerException
> at
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:1633)
> at org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:849)
> at
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:260)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1056)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1026)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:134)
> at
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:59)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:501)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.lang.Thread.run(Thread.java:748)
> '],
> 'message' => 'NullPointerException: (null exception message)',
> 'sql_state' => '0',
> 'error_code' => 4294967295
> }
> {noformat}
> It work well when *_parameter_values_* is not empty list.
> Perhaps it was necessary to create issue in calcite avatica project, but I
> decided to try it here, since I still use queryserver.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (PHOENIX-6602) NullPointerException when send ExectuteRequest via protobuf with no parameters
[
https://issues.apache.org/jira/browse/PHOENIX-6602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448507#comment-17448507
]
Aleksey Stavrov commented on PHOENIX-6602:
--
> Am I right to assume that you are writing a native perl client for Avatica /
> PQS?
Yes, i'm writing perl driver for apache avatica. I use
Google::Protocol::Buffers::Dynamic for that.
> You may want to discuss that on either or both of the Avatica and Phoenix
> mailing lists, as that has a wider exposure than a ticket.
Yes, it's great, but I don't know what to write about.
> you'd better work around this in the meantime
It looks like I will have to do workaround, because the perl DBI defining many
functions based on the "prepare(sql)" and "execute(bind_params)" functions.
The problem is that first the "prepare" function is called, where the number of
parameters is not specified, and only then the "execute" function is called.
> NullPointerException when send ExectuteRequest via protobuf with no parameters
> --
>
> Key: PHOENIX-6602
> URL: https://issues.apache.org/jira/browse/PHOENIX-6602
> Project: Phoenix
> Issue Type: Bug
> Components: queryserver
>Affects Versions: queryserver-6.0.0
> Environment:
>Reporter: Aleksey Stavrov
>Priority: Major
>
> ExecuteRequest has following format:
> {noformat}
> message ExecuteRequest {
> StatementHandle statementHandle = 1;
> repeated TypedValue parameter_values = 2;
> uint64 deprecated_first_frame_max_size = 3;
> bool has_parameter_values = 4;
> int32 first_frame_max_size = 5;
> }
> {noformat}
> When i try to set *_has_parameter_values_* to _*false*_ and set 0 parameters
> then i get error:
> {noformat}
> 'protocol' => {
> 'severity' => 0,
> 'exceptions' => [
> 'java.lang.NullPointerException
> at
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:1633)
> at org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:849)
> at
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:260)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1056)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1026)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:134)
> at
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:59)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:501)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.lang.Thread.run(Thread.java:748)
> '],
> 'message' => 'NullPointerException: (null exception message)',
> 'sql_state' => '0',
> 'error_code' => 4294967295
> }
> {noformat}
> It work well when *_parameter_values_* is not empty list.
> Perhaps it was necessary to create issue in calcite avatica project, but I
> decided to try it here, since I still use queryserver.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (PHOENIX-6602) NullPointerException when send ExectuteRequest via protobuf with no parameters
[
https://issues.apache.org/jira/browse/PHOENIX-6602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448451#comment-17448451
]
Aleksey Stavrov commented on PHOENIX-6602:
--
[~stoty] thanks for help.
I created [issue|https://issues.apache.org/jira/browse/CALCITE-4900] in calcite
project. And it seems i
[found|https://github.com/apache/calcite-avatica/pull/163] a problem.
> NullPointerException when send ExectuteRequest via protobuf with no parameters
> --
>
> Key: PHOENIX-6602
> URL: https://issues.apache.org/jira/browse/PHOENIX-6602
> Project: Phoenix
> Issue Type: Bug
> Components: queryserver
>Affects Versions: queryserver-6.0.0
> Environment:
>Reporter: Aleksey Stavrov
>Priority: Major
>
> ExecuteRequest has following format:
> {noformat}
> message ExecuteRequest {
> StatementHandle statementHandle = 1;
> repeated TypedValue parameter_values = 2;
> uint64 deprecated_first_frame_max_size = 3;
> bool has_parameter_values = 4;
> int32 first_frame_max_size = 5;
> }
> {noformat}
> When i try to set *_has_parameter_values_* to _*false*_ and set 0 parameters
> then i get error:
> {noformat}
> 'protocol' => {
> 'severity' => 0,
> 'exceptions' => [
> 'java.lang.NullPointerException
> at
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:1633)
> at org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:849)
> at
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:260)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1056)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1026)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:134)
> at
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:59)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:501)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.lang.Thread.run(Thread.java:748)
> '],
> 'message' => 'NullPointerException: (null exception message)',
> 'sql_state' => '0',
> 'error_code' => 4294967295
> }
> {noformat}
> It work well when *_parameter_values_* is not empty list.
> Perhaps it was necessary to create issue in calcite avatica project, but I
> decided to try it here, since I still use queryserver.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
