[jira] [Commented] (CALCITE-1187) JSON error code is misreported as -1
[
https://issues.apache.org/jira/browse/CALCITE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15229642#comment-15229642
]
Kevin Liew commented on CALCITE-1187:
-
Yes, we get `1` as the error code for protobuf.
Also I got mixed up and meant protobuf when I indicated rapidjson in my
previous post.
To clarify, I saw `-1` over the wire using `JSON` serialization and
deserialized to `-1` in rapidjson. Using `PROTOBUF`, I deserialized
`4294967295` but I didn't check what was received over the wire.
bq. Should be pretty simple to just catch when we got a SQLException and
populate the ErrorMessage appropriately. Will just take some testing to make
sure the Exception-unwrapping logic is sound.
Great, thanks! Incidentally, we're most interested in NoSuchConnectionException
for the moment. We can throw a generic exception for `-1` for now.
> JSON error code is misreported as -1
>
>
> Key: CALCITE-1187
> URL: https://issues.apache.org/jira/browse/CALCITE-1187
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
> Environment: Phoenix 4.7.0 release on Calcite 1.5.0
>Reporter: Kevin Liew
>Priority: Minor
> Labels: errorCode, exception
>
> Whereas protobuf error code is 4294967295 for TableNotFoundException
> {code:javascript}
> {
> "response": "error",
> "exceptions": [
> "java.lang.RuntimeException:
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:651)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:677)\n\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:177)\n\tat
>
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1113)\n\tat
>
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1091)\n\tat
>
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
>
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
>
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by:
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP\n\tat
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:414)\n\tat
>
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:285)\n\tat
>
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:186)\n\tat
>
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:392)\n\tat
>
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:373)\n\tat
>
> org.apache.phoenix.jdbc.PhoenixPreparedStatement.getMetaData(PhoenixPreparedStatement.java:223)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:669)\n\t...
> 15 more\n"
> ],
> "errorMessage": "RuntimeException:
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP -> TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP",
> "errorCode": -1,
> "sqlState": "0",
> "severity": "UNKNOWN",
> "rpcMetadata": {
> "response": "rpcMetadata",
> "serverAddress": "7adb23b9e2ee:8765"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1192) Document protobuf and json REP types with examples
Francis Chuang created CALCITE-1192: --- Summary: Document protobuf and json REP types with examples Key: CALCITE-1192 URL: https://issues.apache.org/jira/browse/CALCITE-1192 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Francis Chuang It would be nice to have the documentation for the Rep types here (https://calcite.apache.org/docs/avatica_protobuf_reference.html#rep) documented with examples to show what the serialized representation looks like. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1190) Cross-Version Compatibility Test Harness
[ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228875#comment-15228875 ] Julian Hyde commented on CALCITE-1190: -- Wikipedia has a page on TCK https://en.wikipedia.org/wiki/Technology_Compatibility_Kit but I don't believe that the term is specific to the Java platform. It's just a test suite with inversion of control. Apache Harmony (mentioned in the wikipedia page) is an interesting (and sad) case, because it was a war fought over a TCK. > Cross-Version Compatibility Test Harness > > > Key: CALCITE-1190 > URL: https://issues.apache.org/jira/browse/CALCITE-1190 > Project: Calcite > Issue Type: Test > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > One thing that the Protobuf serialization aimed to provide was a library > which provides us the tools to make Avatica compatible across versions. > However, Protobuf is just a tool and the developers can still misuse protobuf > in such a way that breaks compatibility across versions. Not to mention, > compatibility isn't even remotely certain without any tests. > Because of Avatica's position as a library less than a product, we have to > defer some logic to the concrete product being tested (e.g. Phoenix or > Drill). I'm thinking something like the following: > The user provides pairs of client and server "definitions" for a given > version of compatibility. This would include some version of Avatica and some > backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or > Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1. > The client half would be some template for the appropriate JDBC url to use > (sans the URL to the Avatica server) and a JAR file containing the necessary > classes to run the j.s.Driver. The server half would just be a URL to the > Avatica server instance. > The test harness itself can provide the logic to test the remote driver > against the other servers, enumerating the possible combinations of > client-server communication. Starting the server for each version to test is > likely too difficult to automate well given the unknown of what the server > will be, so that will be left as a prerequisite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1190) Cross-Version Compatibility Test Harness
[ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228857#comment-15228857 ] Julian Hyde edited comment on CALCITE-1190 at 4/6/16 6:42 PM: -- Makes sense. You're talking about what I call a TCK. It is a module that can be used by another product to create a test suite. The other product implements callbacks to provide the test environment, and runs the TCK as part of its own test suite. I just created olap4j-tck which is very similar: https://github.com/olap4j/olap4j/tree/olap4j2/tck. Note that the code lives under src/main/java (not src/test/java) and it depends on junit (not in test scope). Mondrian provides an olap4j driver, and uses olap4j-tck to make sure that its olap4j driver is compliant. There is an assumption that any user of the tck would provide the same basic schema (in the case of olap4j-tck, that is the Foodmart Sales cube). was (Author: julianhyde): Makes sense. You're talking about what I call a TCK. It is a module that can be used by another product to create a test suite. The other product implements callbacks to provide the test environment, and runs the TCK as part of its own test suite. I just created olap4j-tck which is very similar: https://github.com/olap4j/olap4j/tree/olap4j2/tck. Note that the code lives under src/main/java (not src/test/java) and it depends on junit (not in test scope). > Cross-Version Compatibility Test Harness > > > Key: CALCITE-1190 > URL: https://issues.apache.org/jira/browse/CALCITE-1190 > Project: Calcite > Issue Type: Test > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > One thing that the Protobuf serialization aimed to provide was a library > which provides us the tools to make Avatica compatible across versions. > However, Protobuf is just a tool and the developers can still misuse protobuf > in such a way that breaks compatibility across versions. Not to mention, > compatibility isn't even remotely certain without any tests. > Because of Avatica's position as a library less than a product, we have to > defer some logic to the concrete product being tested (e.g. Phoenix or > Drill). I'm thinking something like the following: > The user provides pairs of client and server "definitions" for a given > version of compatibility. This would include some version of Avatica and some > backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or > Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1. > The client half would be some template for the appropriate JDBC url to use > (sans the URL to the Avatica server) and a JAR file containing the necessary > classes to run the j.s.Driver. The server half would just be a URL to the > Avatica server instance. > The test harness itself can provide the logic to test the remote driver > against the other servers, enumerating the possible combinations of > client-server communication. Starting the server for each version to test is > likely too difficult to automate well given the unknown of what the server > will be, so that will be left as a prerequisite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1190) Cross-Version Compatibility Test Harness
[ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228867#comment-15228867 ] Josh Elser commented on CALCITE-1190: - Hah, I was going to go digging through some projects that you contributed to looking for some inspiration. Thanks for saving me the effort! > Cross-Version Compatibility Test Harness > > > Key: CALCITE-1190 > URL: https://issues.apache.org/jira/browse/CALCITE-1190 > Project: Calcite > Issue Type: Test > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > One thing that the Protobuf serialization aimed to provide was a library > which provides us the tools to make Avatica compatible across versions. > However, Protobuf is just a tool and the developers can still misuse protobuf > in such a way that breaks compatibility across versions. Not to mention, > compatibility isn't even remotely certain without any tests. > Because of Avatica's position as a library less than a product, we have to > defer some logic to the concrete product being tested (e.g. Phoenix or > Drill). I'm thinking something like the following: > The user provides pairs of client and server "definitions" for a given > version of compatibility. This would include some version of Avatica and some > backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or > Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1. > The client half would be some template for the appropriate JDBC url to use > (sans the URL to the Avatica server) and a JAR file containing the necessary > classes to run the j.s.Driver. The server half would just be a URL to the > Avatica server instance. > The test harness itself can provide the logic to test the remote driver > against the other servers, enumerating the possible combinations of > client-server communication. Starting the server for each version to test is > likely too difficult to automate well given the unknown of what the server > will be, so that will be left as a prerequisite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1190) Cross-Version Compatibility Test Harness
[ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228857#comment-15228857 ] Julian Hyde edited comment on CALCITE-1190 at 4/6/16 6:40 PM: -- Makes sense. You're talking about what I call a TCK. It is a module that can be used by another product to create a test suite. The other product implements callbacks to provide the test environment, and runs the TCK as part of its own test suite. I just created olap4j-tck which is very similar: https://github.com/olap4j/olap4j/tree/olap4j2/tck. Note that the code lives under src/main/java (not src/test/java) and it depends on junit (not in test scope). was (Author: julianhyde): Makes sense. You're talking about what I call a TCK. It is a module that can be used by another product to create a test suite. The other product implements callbacks to provide the test environment. I just created olap4j-tck which is very similar: https://github.com/olap4j/olap4j/tree/olap4j2/tck. Note that the code lives under src/main/java (not src/test/java) and it depends on junit (not in test scope). > Cross-Version Compatibility Test Harness > > > Key: CALCITE-1190 > URL: https://issues.apache.org/jira/browse/CALCITE-1190 > Project: Calcite > Issue Type: Test > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > One thing that the Protobuf serialization aimed to provide was a library > which provides us the tools to make Avatica compatible across versions. > However, Protobuf is just a tool and the developers can still misuse protobuf > in such a way that breaks compatibility across versions. Not to mention, > compatibility isn't even remotely certain without any tests. > Because of Avatica's position as a library less than a product, we have to > defer some logic to the concrete product being tested (e.g. Phoenix or > Drill). I'm thinking something like the following: > The user provides pairs of client and server "definitions" for a given > version of compatibility. This would include some version of Avatica and some > backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or > Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1. > The client half would be some template for the appropriate JDBC url to use > (sans the URL to the Avatica server) and a JAR file containing the necessary > classes to run the j.s.Driver. The server half would just be a URL to the > Avatica server instance. > The test harness itself can provide the logic to test the remote driver > against the other servers, enumerating the possible combinations of > client-server communication. Starting the server for each version to test is > likely too difficult to automate well given the unknown of what the server > will be, so that will be left as a prerequisite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1190) Cross-Version Compatibility Test Harness
[ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228857#comment-15228857 ] Julian Hyde commented on CALCITE-1190: -- Makes sense. You're talking about what I call a TCK. It is a module that can be used by another product to create a test suite. The other product implements callbacks to provide the test environment. I just created olap4j-tck which is very similar: https://github.com/olap4j/olap4j/tree/olap4j2/tck. Note that the code lives under src/main/java (not src/test/java) and it depends on junit (not in test scope). > Cross-Version Compatibility Test Harness > > > Key: CALCITE-1190 > URL: https://issues.apache.org/jira/browse/CALCITE-1190 > Project: Calcite > Issue Type: Test > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > One thing that the Protobuf serialization aimed to provide was a library > which provides us the tools to make Avatica compatible across versions. > However, Protobuf is just a tool and the developers can still misuse protobuf > in such a way that breaks compatibility across versions. Not to mention, > compatibility isn't even remotely certain without any tests. > Because of Avatica's position as a library less than a product, we have to > defer some logic to the concrete product being tested (e.g. Phoenix or > Drill). I'm thinking something like the following: > The user provides pairs of client and server "definitions" for a given > version of compatibility. This would include some version of Avatica and some > backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or > Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1. > The client half would be some template for the appropriate JDBC url to use > (sans the URL to the Avatica server) and a JAR file containing the necessary > classes to run the j.s.Driver. The server half would just be a URL to the > Avatica server instance. > The test harness itself can provide the logic to test the remote driver > against the other servers, enumerating the possible combinations of > client-server communication. Starting the server for each version to test is > likely too difficult to automate well given the unknown of what the server > will be, so that will be left as a prerequisite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1187) JSON error code is misreported as -1
[
https://issues.apache.org/jira/browse/CALCITE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228681#comment-15228681
]
Josh Elser commented on CALCITE-1187:
-
bq. We are getting `1` for NoSuchConnectionException on the protobuf client.
{{1}} as the errorCode? Maybe I filled that one out by hand. I vaguely recall
setting a few by hand that were avatica-focused.
bq. Is this still on the to-do list or do we need to implement error-message
parsing for the JSON client?
Should be pretty simple to just catch when we got a SQLException and populate
the ErrorMessage appropriately. Will just take some testing to make sure the
Exception-unwrapping logic is sound.
bq. It looks like it is `-1` over the wire and 4294967295 when we use rapidjson
to read it as uint32 (side-effect of reading a negative integer into an
unsigned -type).
Ah, that makes sense.
> JSON error code is misreported as -1
>
>
> Key: CALCITE-1187
> URL: https://issues.apache.org/jira/browse/CALCITE-1187
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
> Environment: Phoenix 4.7.0 release on Calcite 1.5.0
>Reporter: Kevin Liew
>Priority: Minor
> Labels: errorCode, exception
>
> Whereas protobuf error code is 4294967295 for TableNotFoundException
> {code:javascript}
> {
> "response": "error",
> "exceptions": [
> "java.lang.RuntimeException:
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:651)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:677)\n\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:177)\n\tat
>
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1113)\n\tat
>
> org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1091)\n\tat
>
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
>
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
>
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by:
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP\n\tat
> org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:414)\n\tat
>
> org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:285)\n\tat
>
> org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:186)\n\tat
>
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:392)\n\tat
>
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:373)\n\tat
>
> org.apache.phoenix.jdbc.PhoenixPreparedStatement.getMetaData(PhoenixPreparedStatement.java:223)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:669)\n\t...
> 15 more\n"
> ],
> "errorMessage": "RuntimeException:
> org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP -> TableNotFoundException: ERROR 1012 (42M03): Table
> undefined. tableName=EMP",
> "errorCode": -1,
> "sqlState": "0",
> "severity": "UNKNOWN",
> "rpcMetadata": {
> "response": "rpcMetadata",
> "serverAddress": "7adb23b9e2ee:8765"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1190) Cross-Version Compatibility Test Harness
[ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228679#comment-15228679 ] Josh Elser commented on CALCITE-1190: - Actually, maybe a good first stab is to just implement an HSQLDB avatica server impl that we can provide avatica jars at runtime? Same approach, but we wouldn't have to depend on Phoenix/Drill/etc to wire it up. > Cross-Version Compatibility Test Harness > > > Key: CALCITE-1190 > URL: https://issues.apache.org/jira/browse/CALCITE-1190 > Project: Calcite > Issue Type: Test > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > One thing that the Protobuf serialization aimed to provide was a library > which provides us the tools to make Avatica compatible across versions. > However, Protobuf is just a tool and the developers can still misuse protobuf > in such a way that breaks compatibility across versions. Not to mention, > compatibility isn't even remotely certain without any tests. > Because of Avatica's position as a library less than a product, we have to > defer some logic to the concrete product being tested (e.g. Phoenix or > Drill). I'm thinking something like the following: > The user provides pairs of client and server "definitions" for a given > version of compatibility. This would include some version of Avatica and some > backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or > Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1. > The client half would be some template for the appropriate JDBC url to use > (sans the URL to the Avatica server) and a JAR file containing the necessary > classes to run the j.s.Driver. The server half would just be a URL to the > Avatica server instance. > The test harness itself can provide the logic to test the remote driver > against the other servers, enumerating the possible combinations of > client-server communication. Starting the server for each version to test is > likely too difficult to automate well given the unknown of what the server > will be, so that will be left as a prerequisite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
