[jira] [Created] (CALCITE-962) Server-side exception (stack trace) not propagated in JdbcMeta.propagate
Josh Elser created CALCITE-962:
--
Summary: Server-side exception (stack trace) not propagated in
JdbcMeta.propagate
Key: CALCITE-962
URL: https://issues.apache.org/jira/browse/CALCITE-962
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: 1.5.0
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: next
Noticed the following in some automated tests against Phoenix:
{noformat}
java.lang.RuntimeException: Encountered exception in sub plan [0] execution.
at org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:645)
at
org.apache.calcite.avatica.jdbc.JdbcMeta.prepareAndExecute(JdbcMeta.java:709)
at org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:179)
at
org.apache.calcite.avatica.remote.Service$PrepareAndExecuteRequest.accept(Service.java:1049)
at
org.apache.calcite.avatica.remote.Service$PrepareAndExecuteRequest.accept(Service.java:1023)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:100)
at org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)
at
org.apache.calcite.avatica.server.AvaticaHandler.handle(AvaticaHandler.java:68)
at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:497)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
{noformat}
The good part, we got this exception from the server on the client! Oddly, we
didn't get an actual exception from Phoenix. It looks like we happened to drop
that context.
{code}
private RuntimeException propagate(Throwable e) {
if (e instanceof RuntimeException) {
throw (RuntimeException) e;
} else if (e instanceof Error) {
throw (Error) e;
} else {
throw new RuntimeException(e.getMessage());
}
}
{code}
The else branch happened to drop the context from the cause. We want to be sure
to propagate this back to clients.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-964) Rename "timezone" connection property to "timeZone"
[ https://issues.apache.org/jira/browse/CALCITE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005066#comment-15005066 ] Josh Elser commented on CALCITE-964: LGTM. Thanks for adding the comment to JdbcMetaTest.java. > Rename "timezone" connection property to "timeZone" > --- > > Key: CALCITE-964 > URL: https://issues.apache.org/jira/browse/CALCITE-964 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Rename "timezone" connection property to "timeZone", to be consistent with > java.util.TimeZone (two words in camel case). Also rename > CalciteConnectionProperty.TIMEZONE and BuiltInConnectionProperty.TIMEZONE to > TIME_ZONE. > ConnectionConfig.timeZone() is already OK. > Connect string properties are matched case-insensitively, and so > "jdbc:calcite:timezone=gmt+3" will continue to work. So will "timeZone", > "TIME_ZONE", "TIMEZONE". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-994) Calcite development under Eclipse IDE
[ https://issues.apache.org/jira/browse/CALCITE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030042#comment-15030042 ] Josh Elser commented on CALCITE-994: bq. based on what I've seen in Hbase and Oodt it seems to be the norm. Yeah, that's my assessment. XML lends itself well to folding of unwanted sections ;) bq. by including a lifecycleMappingMetadata section in pom.xml. Could we do the same here? I would assume so. LIke Alexander pointed out, it would be nice to have m2e support for these plugins (esp the javacc plugin so that Eclipse would automagically get regenerated, but not critical since I assume it's not often changed), but is fine for most cases. I have a backlog of other stuff to look at today, but I'll try to circle around. Thanks for filing this, Alexander! > Calcite development under Eclipse IDE > - > > Key: CALCITE-994 > URL: https://issues.apache.org/jira/browse/CALCITE-994 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Alexander Reshetov >Assignee: Julian Hyde >Priority: Minor > Attachments: lifecycle-mapping-metadata.xml > > > After "git clone" project could not be imported in Eclipse as existing Maven > project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-767) Commit functionality not exposed by the RPC server
[ https://issues.apache.org/jira/browse/CALCITE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-767: -- Assignee: Josh Elser > Commit functionality not exposed by the RPC server > -- > > Key: CALCITE-767 > URL: https://issues.apache.org/jira/browse/CALCITE-767 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Lukas Lalinsky >Assignee: Josh Elser > > It seems that the commit/rollback functionality is not exposed by the RPC > server, which means that it's only usable in autocommit mode. Avatica itself > doesn't have a concept of commit in the RPC and the remote JDBC connection > raises an exception when calling commit() on it, but Phoenix's native JDBC > connection does implement commit(), so the RPC needs to be extended to allow > calling that remotely. > The easiest way to test this, "!autocommit off" and then "!commit" fails in > "sqline-thin.py", but works in "sqline.py". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-994) Calcite development under Eclipse IDE
[ https://issues.apache.org/jira/browse/CALCITE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15041826#comment-15041826 ] Josh Elser commented on CALCITE-994: [~areshetov], that is curious. I wonder why that isn't getting picked up. We might need to lift the configuration for the maven-checkstyle-plugin from the execution to the plugin itself for manual invocation of the goal to work as expected. Does that make sense? > Calcite development under Eclipse IDE > - > > Key: CALCITE-994 > URL: https://issues.apache.org/jira/browse/CALCITE-994 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Alexander Reshetov >Assignee: Julian Hyde >Priority: Minor > Attachments: lifecycle-mapping-metadata.xml > > > After "git clone" project could not be imported in Eclipse as existing Maven > project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-989) Provide generic server metadata in responses
[ https://issues.apache.org/jira/browse/CALCITE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-989. Resolution: Fixed Fixed some static analysis finds in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=d259cad23d396cef213f6e773f2e22e205f4230c > Provide generic server metadata in responses > > > Key: CALCITE-989 > URL: https://issues.apache.org/jira/browse/CALCITE-989 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 1.6.0 > > > Some follow on from CALCITE-903: > The assumption in that work was that the common case in running behind a > load-balancer is that a given client would continue to be routed back to the > same avatica server instance. Sadly, this is not necessarily reality. > If the only load balancer technology available is only capable of an > round-robin algorithm (or similar), we need to provide the information for a > client to make a decision to return to the same server upon subsequent > requests (e.g. fetching the next page of results). > Thinking more generally, the server which processed a given request is just > general metadata. We could include things like the Avatica version, the > "real" JDBC version information, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-983) NPE in ErrorResponse construction
[
https://issues.apache.org/jira/browse/CALCITE-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-983.
Resolution: Fixed
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=cd58fe73f29dd576ac2525f22c34e9b3d4df1913
> NPE in ErrorResponse construction
> -
>
> Key: CALCITE-983
> URL: https://issues.apache.org/jira/browse/CALCITE-983
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> Noticed today:
> {noformat}
> 2015-11-18 19:44:29,314 WARN org.eclipse.jetty.server.HttpChannel: /
> java.lang.NullPointerException
> at
> org.apache.calcite.avatica.proto.Responses$ErrorResponse$Builder.setErrorMessage(Responses.java:7180)
> at
> org.apache.calcite.avatica.remote.Service$ErrorResponse.serialize(Service.java:2574)
> at
> org.apache.calcite.avatica.remote.Service$ErrorResponse.serialize(Service.java:2495)
> at
> org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:195)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:46)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:28)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:106)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:38)
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:63)
> at
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Looks like we expected something to be non-null at this point, but didn't
> cover all avenues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1006) Enable maven-findbugs-plugin
Josh Elser created CALCITE-1006: --- Summary: Enable maven-findbugs-plugin Key: CALCITE-1006 URL: https://issues.apache.org/jira/browse/CALCITE-1006 Project: Calcite Issue Type: Task Components: build Reporter: Josh Elser Assignee: Josh Elser We can fairly trivially wire up the maven-findbugs-plugin to get some static-analysis at build time. This is my tool of choice for the matter -- I'll make sure we have some sane configuration and try to knock out any issues that it reports. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-934) Use ephemeral port for CalciteRemoteDriverTest
[
https://issues.apache.org/jira/browse/CALCITE-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-934.
Resolution: Fixed
Fix Version/s: (was: next)
1.6.0
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=1bbb6a2b97bf3da149c5f878b2d59ceafa737521
> Use ephemeral port for CalciteRemoteDriverTest
> --
>
> Key: CALCITE-934
> URL: https://issues.apache.org/jira/browse/CALCITE-934
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 1.6.0
>
>
> {noformat}
> java.lang.RuntimeException: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:444)
> at sun.nio.ch.Net.bind(Net.java:436)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at
> org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:321)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at org.eclipse.jetty.server.Server.doStart(Server.java:366)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.apache.calcite.avatica.server.HttpServer.start(HttpServer.java:65)
> at org.apache.calcite.avatica.server.Main.start(Main.java:95)
> at org.apache.calcite.avatica.server.Main.start(Main.java:68)
> at
> org.apache.calcite.jdbc.CalciteRemoteDriverTest.beforeClass(CalciteRemoteDriverTest.java:155)
> {noformat}
> If you have an instance of the Avatica server already running,
> {{CalciteRemoteDriverTest}} fails as above because it fails to bind port 8765.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-767) Commit functionality not exposed by the RPC server
[ https://issues.apache.org/jira/browse/CALCITE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060514#comment-15060514 ] Josh Elser commented on CALCITE-767: This was fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=322b97300d460cf7c98b6002e4f0d5dab455f188 > Commit functionality not exposed by the RPC server > -- > > Key: CALCITE-767 > URL: https://issues.apache.org/jira/browse/CALCITE-767 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Lukas Lalinsky >Assignee: Josh Elser > Fix For: 1.6.0 > > > It seems that the commit/rollback functionality is not exposed by the RPC > server, which means that it's only usable in autocommit mode. Avatica itself > doesn't have a concept of commit in the RPC and the remote JDBC connection > raises an exception when calling commit() on it, but Phoenix's native JDBC > connection does implement commit(), so the RPC needs to be extended to allow > calling that remotely. > The easiest way to test this, "!autocommit off" and then "!commit" fails in > "sqline-thin.py", but works in "sqline.py". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-767) Commit functionality not exposed by the RPC server
[ https://issues.apache.org/jira/browse/CALCITE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059491#comment-15059491 ] Josh Elser commented on CALCITE-767: bq. I'd be interested in seeing your Pherf scenario, Josh Elser. 5x is more degradation that I'd have expected, but I'm sure it depends on the workload. The frustrating part at the moment is that I have no good means to understand where time is being spent. I'm still working through some, what I think is, nonsense logging in pherf, but I'll get back to you on that over in Phoenixlandia :) bq. FWIW, I'm about to implement PHOENIX-2411 which would support the "dumb" load balancer scenario you mentioned. Sick! > Commit functionality not exposed by the RPC server > -- > > Key: CALCITE-767 > URL: https://issues.apache.org/jira/browse/CALCITE-767 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Lukas Lalinsky >Assignee: Josh Elser > Fix For: next > > > It seems that the commit/rollback functionality is not exposed by the RPC > server, which means that it's only usable in autocommit mode. Avatica itself > doesn't have a concept of commit in the RPC and the remote JDBC connection > raises an exception when calling commit() on it, but Phoenix's native JDBC > connection does implement commit(), so the RPC needs to be extended to allow > calling that remotely. > The easiest way to test this, "!autocommit off" and then "!commit" fails in > "sqline-thin.py", but works in "sqline.py". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1027) Support commit/rollback behind "dumb" loadbalancer
Josh Elser created CALCITE-1027: --- Summary: Support commit/rollback behind "dumb" loadbalancer Key: CALCITE-1027 URL: https://issues.apache.org/jira/browse/CALCITE-1027 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Josh Elser Assignee: James Taylor Fix For: next Some follow-on work that I punted on in CALCITE-767 for commit/rollback functionality. We've been trying to keep the Avatica driver functional when sitting behind a generic HTTP load balancer which won't guarantee clients always return to the same backend server. [~jamestaylor] is working on some Phoenix-layer changes that would enable this in PHOENIX-2411, but we'll likely have to make some RPC-level changes for Avatica to help enable Phoenix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-767) Commit functionality not exposed by the RPC server
[ https://issues.apache.org/jira/browse/CALCITE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-767. Resolution: Fixed Fix Version/s: (was: next) 1.6.0 > Commit functionality not exposed by the RPC server > -- > > Key: CALCITE-767 > URL: https://issues.apache.org/jira/browse/CALCITE-767 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Lukas Lalinsky >Assignee: Josh Elser > Fix For: 1.6.0 > > > It seems that the commit/rollback functionality is not exposed by the RPC > server, which means that it's only usable in autocommit mode. Avatica itself > doesn't have a concept of commit in the RPC and the remote JDBC connection > raises an exception when calling commit() on it, but Phoenix's native JDBC > connection does implement commit(), so the RPC needs to be extended to allow > calling that remotely. > The easiest way to test this, "!autocommit off" and then "!commit" fails in > "sqline-thin.py", but works in "sqline.py". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-767) Commit functionality not exposed by the RPC server
[ https://issues.apache.org/jira/browse/CALCITE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059451#comment-15059451 ] Josh Elser commented on CALCITE-767: Did some prelim testing of this using Phoenix and protobuf. Using Phoenix's pherf tool, I was able to run the same test against the normal Phoenix driver and the Avatica-based Phoenix thin driver. For those curious, performance degredation without any thought of optimization in Avatica: 5x. Pretty good for a first pass, IMO. I'm going to rebase/merge this in tonight. > Commit functionality not exposed by the RPC server > -- > > Key: CALCITE-767 > URL: https://issues.apache.org/jira/browse/CALCITE-767 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Lukas Lalinsky >Assignee: Josh Elser > Fix For: next > > > It seems that the commit/rollback functionality is not exposed by the RPC > server, which means that it's only usable in autocommit mode. Avatica itself > doesn't have a concept of commit in the RPC and the remote JDBC connection > raises an exception when calling commit() on it, but Phoenix's native JDBC > connection does implement commit(), so the RPC needs to be extended to allow > calling that remotely. > The easiest way to test this, "!autocommit off" and then "!commit" fails in > "sqline-thin.py", but works in "sqline.py". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1040) ColumnValue and TypedValue are unnecessarily both repeated
Josh Elser created CALCITE-1040:
---
Summary: ColumnValue and TypedValue are unnecessarily both repeated
Key: CALCITE-1040
URL: https://issues.apache.org/jira/browse/CALCITE-1040
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: 1.5.0
Reporter: Carter Shanklin
Assignee: Josh Elser
Fix For: 1.6.0
[~cartershanklin] sent me some nice notes from working on a Python interface to
the Phoenix QueryServer. He saw this strange thing in the code he had to write:
{code}
count = response.results[0].first_frame.rows[0].value[0].value[0].number_value
{code}
The {{value\[0\].value\[0\]}} is strange. Looking at the protobuf definition,
it seems like both {{ColumnValue}} and {{TypedValue}} are repeated which is
causing this. Only one of them should be repeated, not both. This creates the
equivalent of a 2dim array inside each row instead of just a 1dim array.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1035) Avatica fetch does not return an update row-count for upsert, delete
[
https://issues.apache.org/jira/browse/CALCITE-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088622#comment-15088622
]
Josh Elser commented on CALCITE-1035:
-
bq. Is this fixed in Calcite?
Unknown. I have not gotten around to trying to reproduce it yet.
> Avatica fetch does not return an update row-count for upsert, delete
>
>
> Key: CALCITE-1035
> URL: https://issues.apache.org/jira/browse/CALCITE-1035
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
> Environment: Hortonworks HDP 2.3 upgraded to Phoenix 4.5.0
>Reporter: Kevin Liew
> Labels: avatica, calcite, fetch, phoenix, prepare, wireprotocol
>
> 1. prepare an upsert or delete
> {noformat}request: {
> "request": "prepare",
> "connectionId": "c28224cd-a688-4117-af44-0d1510918bd8",
> "sql": "upsert into test.integer_table values ('test3', ?)",
> "maxRowCount": -1
> }
> {noformat}
> Response:
> {noformat}
> {
> "response": "prepare",
> "statement": {
> "connectionId": "36acc5c4-0136-874a-2fcf-a3ec747d7FD4",
> "id": 1532322378,
> "signature": {
> "columns": [
>
> ],
> "sql": "upsert into test.integer_table values ('test3', ?)",
> "parameters": [
> {
> "signed": false,
> "precision": 0,
> "scale": 0,
> "parameterType": 4,
> "typeName": "INTEGER",
> "className": "java.lang.Integer",
> "name": "?1"
> }
> ],
> "cursorFactory": {
> "style": "LIST",
> "clazz": null,
> "fieldNames": null
> }
> }
> }
> }
> {noformat}
> 2. execute by calling 'fetch' to Phoenix
> {noformat}
> request: {
> "request": "fetch",
> "connectionId": "36acc5c4-0136-874a-2fcf-a3ec747d7FD4",
> "statementId": 1532322378,
> "parameterValues": [
> {
> "type": "INTEGER",
> "value": 1
> }
> ],
> "offset": 0,
> "fetchMaxRowCount": 100
> }
> {noformat}
> Result:
> {noformat}
> {
> "response": "fetch",
> "frame": {
> "offset": 0,
> "done": true,
> "rows": [
>
> ]
> }
> }
> {noformat}
> using prepareAndExecute, we get back an update row-count, but
> prepareAndExecute cannot be used for parameterized statements
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1044) Quirky handling of PrepareAndExecuteRequests maxRowCount attribute
Josh Elser created CALCITE-1044:
---
Summary: Quirky handling of PrepareAndExecuteRequests maxRowCount
attribute
Key: CALCITE-1044
URL: https://issues.apache.org/jira/browse/CALCITE-1044
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: 1.5.0
Reporter: Carter Shanklin
Assignee: Josh Elser
Fix For: 1.6.0
Another good find sent to me by [~cartershanklin].
He noticed when using the Protobuf wire API directly, provided a value of 0 for
{{maxRowCount}} in a {{PrepareAndExecuteRequest}} resulted in no values being
returned.
I dug around a little and found this little tweak done:
{panel:title=AvaticaStatement.java}
{code}
protected void executeInternal(String sql) throws SQLException {
// reset previous state before moving forward.
this.updateCount = -1;
try {
// In JDBC, maxRowCount = 0 means no limit; in prepare it means LIMIT 0
final long maxRowCount1 = maxRowCount <= 0 ? -1 : maxRowCount;
for (int i = 0; i < connection.maxRetriesPerExecute; i++) {
try {
Meta.ExecuteResult x =
connection.prepareAndExecuteInternal(this, sql, maxRowCount1);
{code}
{panel}
It would be nice to also do this correction on the server side to get this
behavior since our wire API so closely matches the JDBC API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-984) Missing Avatica RPC docs: ExecuteRequest, SyncResultsRequest, OpenConnectionRequest
[ https://issues.apache.org/jira/browse/CALCITE-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065932#comment-15065932 ] Josh Elser commented on CALCITE-984: Oh, thank you. I didn't realize we had some already. I'll follow them, and update if necessary. > Missing Avatica RPC docs: ExecuteRequest, SyncResultsRequest, > OpenConnectionRequest > --- > > Key: CALCITE-984 > URL: https://issues.apache.org/jira/browse/CALCITE-984 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: next > > > Went to point someone to the RPC docs for the equivalent call for execute on > a prepared statement and realized the docs were missing. > Giving a glance comparing the current docs to Service.java, I noticed we were > missing ExecuteRequest, SyncResultsRequest, OpenConnectionRequest. Let me add > some docs here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1033) Create Avatica message documentation for protobufs
Josh Elser created CALCITE-1033: --- Summary: Create Avatica message documentation for protobufs Key: CALCITE-1033 URL: https://issues.apache.org/jira/browse/CALCITE-1033 Project: Calcite Issue Type: Improvement Components: site Reporter: Josh Elser Assignee: Josh Elser Fix For: 1.6.0 Need to make documentation for the protocol buffer wire message format for Avatica. While it's "similar" in spirit to the JSON docs, probably not sufficiently similar for people other than me (who wrote it). These docs should help write implementations for Avatica in other languages and help us define the "specification". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1033) Create Avatica message documentation for protobufs
[ https://issues.apache.org/jira/browse/CALCITE-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1033. - Resolution: Fixed Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=60b2825c8a49c62ea3caf2212521809ebc545bd8 > Create Avatica message documentation for protobufs > -- > > Key: CALCITE-1033 > URL: https://issues.apache.org/jira/browse/CALCITE-1033 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 1.6.0 > > > Need to make documentation for the protocol buffer wire message format for > Avatica. > While it's "similar" in spirit to the JSON docs, probably not sufficiently > similar for people other than me (who wrote it). > These docs should help write implementations for Avatica in other languages > and help us define the "specification". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-984) Missing Avatica RPC docs: ExecuteRequest, SyncResultsRequest, OpenConnectionRequest
[
https://issues.apache.org/jira/browse/CALCITE-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-984.
Resolution: Fixed
Fix Version/s: (was: next)
1.6.0
Ok, prod site should be updated now. I only copied in {{docs/}} as my changes
were limited there (to the best of my knowledge)
> Missing Avatica RPC docs: ExecuteRequest, SyncResultsRequest,
> OpenConnectionRequest
> ---
>
> Key: CALCITE-984
> URL: https://issues.apache.org/jira/browse/CALCITE-984
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> Went to point someone to the RPC docs for the equivalent call for execute on
> a prepared statement and realized the docs were missing.
> Giving a glance comparing the current docs to Service.java, I noticed we were
> missing ExecuteRequest, SyncResultsRequest, OpenConnectionRequest. Let me add
> some docs here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1029) Add "purpose" explanations to Avatica JSON docs
[ https://issues.apache.org/jira/browse/CALCITE-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1029. - Resolution: Fixed Fix Version/s: (was: next) 1.6.0 Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=e7bbcec8f451dbc2b02434eba6d17138e1d44e6e > Add "purpose" explanations to Avatica JSON docs > --- > > Key: CALCITE-1029 > URL: https://issues.apache.org/jira/browse/CALCITE-1029 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 1.6.0 > > > Looking at the JSON docs again, they serve as a easily viewable/readable > source for what objects (requests, responses, and "other") might be used with > the JSON API. An area in which it is lacking is how each of these objects is > actually used. > Add a brief explanation to each object that describe how (and why, if > necessary to give adequate explanation to "how") each are used, similar to a > class-level Javadoc comment feel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-984) Missing Avatica RPC docs: ExecuteRequest, SyncResultsRequest, OpenConnectionRequest
[ https://issues.apache.org/jira/browse/CALCITE-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064596#comment-15064596 ] Josh Elser commented on CALCITE-984: Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=1c5eddd0494f8b292736a4c6e300da4c697235f0 (holding off closing until I get things updated) [~julianhyde], do we have instructions on how to update the production website anywhere? I'd like to be able to know how to update it so that I don't always have to bug you :) > Missing Avatica RPC docs: ExecuteRequest, SyncResultsRequest, > OpenConnectionRequest > --- > > Key: CALCITE-984 > URL: https://issues.apache.org/jira/browse/CALCITE-984 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: next > > > Went to point someone to the RPC docs for the equivalent call for execute on > a prepared statement and realized the docs were missing. > Giving a glance comparing the current docs to Service.java, I noticed we were > missing ExecuteRequest, SyncResultsRequest, OpenConnectionRequest. Let me add > some docs here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1029) Add "purpose" explanations to Avatica JSON docs
Josh Elser created CALCITE-1029: --- Summary: Add "purpose" explanations to Avatica JSON docs Key: CALCITE-1029 URL: https://issues.apache.org/jira/browse/CALCITE-1029 Project: Calcite Issue Type: Improvement Components: site Reporter: Josh Elser Assignee: Josh Elser Fix For: next Looking at the JSON docs again, they serve as a easily viewable/readable source for what objects (requests, responses, and "other") might be used with the JSON API. An area in which it is lacking is how each of these objects is actually used. Add a brief explanation to each object that describe how (and why, if necessary to give adequate explanation to "how") each are used, similar to a class-level Javadoc comment feel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1025) Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client
[ https://issues.apache.org/jira/browse/CALCITE-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1025: Assignee: Phillip Rhodes (was: Julian Hyde) > Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client > > > Key: CALCITE-1025 > URL: https://issues.apache.org/jira/browse/CALCITE-1025 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Phillip Rhodes >Assignee: Phillip Rhodes > Attachments: AvaticaConnection.patch, Driver.patch, > RemoteService.patch, http_auth_patch.patch, patch_against_1.2.0.patch > > > Avatica serves as the base for the Phoenix "thin" JDBC driver, and supports a > JSON over HTTP protocol. Being that it is HTTP, it would be desirable to > support standard HTTP mechanisms like HTTP BASIC authentication, which is > required by some proxy servers (for example, Knox). > In particular, I've been working on deploying Phoenix behind Knox with Knox > mediating JDBC access using the "thin" driver based on Avatica. In order to > make this work, I had to make a small change to Avatica in order to take the > supplied credentials and construct an Authorization header, and add it to the > HTTP request. > I have made this change and verified that it works, and would like to propose > merging it into the Avatica source. I have two versions, one made against > HEAD and another which is a backport to an older version of Avatica (turns > out this was needed for the specific environment we were deploying in). > It is a fairly small change, totaling about 10-15 lines of code, and - as far > as I can tell - should be totally non-invasive to existing users of Avatica. > Basically I just add the HTTP Authorization header IF a username/password > combo is present, and do nothing otherwise. If it is desired, we could also > wrap this code in a parameter based on a query string parameter or something. > Maybe "enableProxyAuth=true" or something along those lines. > I'll attach the actual modified code shortly, but in the meantime wanted to > start a discussion around this proposed change. I have run this by some > people inside HortonWorks and they are in favor of implementing this so that > it can become part of HDP. Being able to use Knox (or, in theory, any other > proxy server) to mediate JDBC access to Phoenix seems to be a desirable > thing. Thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-982) Improve debug-ability when failing to parse serialized messages over RPC
Josh Elser created CALCITE-982:
--
Summary: Improve debug-ability when failing to parse serialized
messages over RPC
Key: CALCITE-982
URL: https://issues.apache.org/jira/browse/CALCITE-982
Project: Calcite
Issue Type: Improvement
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: next
A pain that I keep running into while running some higher-level tests with
Phoenix is that when the client or server cannot parse a message over HTTP,
there's a very unhelpful message that is printed.
For example, with protobuf:
{noformat}
java.lang.RuntimeException:
org.apache.calcite.avatica.com.google.protobuf.InvalidProtocolBufferException:
Protocol message end-group tag did not match expected tag.
at
org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:41)
at
org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:75)
at
org.apache.calcite.avatica.remote.RemoteMeta$1.call(RemoteMeta.java:88)
at
org.apache.calcite.avatica.remote.RemoteMeta$1.call(RemoteMeta.java:84)
at
org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:666)
at
org.apache.calcite.avatica.remote.RemoteMeta.createStatement(RemoteMeta.java:83)
at
org.apache.calcite.avatica.AvaticaStatement.(AvaticaStatement.java:108)
at
org.apache.calcite.avatica.AvaticaStatement.(AvaticaStatement.java:94)
at
org.apache.calcite.avatica.AvaticaJdbc41Factory$AvaticaJdbc41Statement.(AvaticaJdbc41Factory.java:114)
at
org.apache.calcite.avatica.AvaticaJdbc41Factory.newStatement(AvaticaJdbc41Factory.java:73)
at
org.apache.calcite.avatica.AvaticaConnection.createStatement(AvaticaConnection.java:300)
at
org.apache.calcite.avatica.AvaticaConnection.createStatement(AvaticaConnection.java:146)
at
org.apache.calcite.avatica.MetaImpl.createResultSet(MetaImpl.java:256)
at
org.apache.calcite.avatica.MetaImpl.createEmptyResultSet(MetaImpl.java:215)
at org.apache.calcite.avatica.MetaImpl.getPrimaryKeys(MetaImpl.java:657)
at
org.apache.calcite.avatica.AvaticaDatabaseMetaData$18.call(AvaticaDatabaseMetaData.java:906)
at
org.apache.calcite.avatica.AvaticaDatabaseMetaData$18.call(AvaticaDatabaseMetaData.java:903)
at
org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:666)
at
org.apache.calcite.avatica.AvaticaDatabaseMetaData.getPrimaryKeys(AvaticaDatabaseMetaData.java:902)
at sqlline.Rows.isPrimaryKey(Rows.java:78)
at sqlline.TableOutputFormat.getOutputString(TableOutputFormat.java:106)
at sqlline.TableOutputFormat.getOutputString(TableOutputFormat.java:91)
at sqlline.TableOutputFormat.print(TableOutputFormat.java:35)
at sqlline.SqlLine.print(SqlLine.java:1653)
at sqlline.Commands.execute(Commands.java:833)
at sqlline.Commands.sql(Commands.java:732)
at sqlline.SqlLine.dispatch(SqlLine.java:808)
at sqlline.SqlLine.runCommands(SqlLine.java:1711)
at sqlline.Commands.run(Commands.java:1285)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
at sqlline.SqlLine.dispatch(SqlLine.java:804)
at sqlline.SqlLine.initArgs(SqlLine.java:613)
at sqlline.SqlLine.begin(SqlLine.java:656)
at sqlline.SqlLine.start(SqlLine.java:398)
at sqlline.SqlLine.main(SqlLine.java:292)
Caused by:
org.apache.calcite.avatica.com.google.protobuf.InvalidProtocolBufferException:
Protocol message end-group tag did not match expected tag.
at
org.apache.calcite.avatica.com.google.protobuf.InvalidProtocolBufferException.invalidEndTag(InvalidProtocolBufferException.java:94)
at
org.apache.calcite.avatica.com.google.protobuf.CodedInputStream.checkLastTagWas(CodedInputStream.java:174)
at
org.apache.calcite.avatica.com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:139)
at
org.apache.calcite.avatica.com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:168)
at
org.apache.calcite.avatica.com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:180)
at
org.apache.calcite.avatica.com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:185)
at
org.apache.calcite.avatica.com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:49)
at
[jira] [Created] (CALCITE-983) NPE in ErrorResponse construction
Josh Elser created CALCITE-983:
--
Summary: NPE in ErrorResponse construction
Key: CALCITE-983
URL: https://issues.apache.org/jira/browse/CALCITE-983
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: next
Noticed today:
{noformat}
2015-11-18 19:44:29,314 WARN org.eclipse.jetty.server.HttpChannel: /
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Responses$ErrorResponse$Builder.setErrorMessage(Responses.java:7180)
at
org.apache.calcite.avatica.remote.Service$ErrorResponse.serialize(Service.java:2574)
at
org.apache.calcite.avatica.remote.Service$ErrorResponse.serialize(Service.java:2495)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:195)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:28)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:106)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:38)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:63)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:497)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Looks like we expected something to be non-null at this point, but didn't cover
all avenues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-989) Provide generic server metadata in responses
[ https://issues.apache.org/jira/browse/CALCITE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023255#comment-15023255 ] Josh Elser commented on CALCITE-989: One concern for a generic "struct" of server metadata-per-response is bloating the size of each Response. CALCITE-836 has a suggestion to expose some Avatica server "metadata" (the avatica server's version). It would be confusing to have RPCs contain this information while having an explicit API for requesting it (via the DatabaseProperty's). Perhaps the only good piece of data per Response is data explicitly about that request/response (and not about the server in general): the server's address and processing time. Maybe there are others I haven't thought of? > Provide generic server metadata in responses > > > Key: CALCITE-989 > URL: https://issues.apache.org/jira/browse/CALCITE-989 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: next > > > Some follow on from CALCITE-903: > The assumption in that work was that the common case in running behind a > load-balancer is that a given client would continue to be routed back to the > same avatica server instance. Sadly, this is not necessarily reality. > If the only load balancer technology available is only capable of an > round-robin algorithm (or similar), we need to provide the information for a > client to make a decision to return to the same server upon subsequent > requests (e.g. fetching the next page of results). > Thinking more generally, the server which processed a given request is just > general metadata. We could include things like the Avatica version, the > "real" JDBC version information, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094627#comment-15094627
]
Josh Elser commented on CALCITE-1052:
-
bq. We are able to reproduce this issue while running the two JDBC applications
on separate machines
That is.. very interesting. Let me look into this. I thought the current use of
our connectionId and statementId should prevent this from happening.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
>
[jira] [Assigned] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1052:
---
Assignee: Josh Elser
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> There are several crashes (might be preventable by adding a
[jira] [Commented] (CALCITE-1040) ColumnValue and TypedValue are unnecessarily both repeated
[
https://issues.apache.org/jira/browse/CALCITE-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15095068#comment-15095068
]
Josh Elser commented on CALCITE-1040:
-
Thanks, Julian.
> ColumnValue and TypedValue are unnecessarily both repeated
> --
>
> Key: CALCITE-1040
> URL: https://issues.apache.org/jira/browse/CALCITE-1040
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Carter Shanklin
>Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> [~cartershanklin] sent me some nice notes from working on a Python interface
> to the Phoenix QueryServer. He saw this strange thing in the code he had to
> write:
> {code}
> count = response.results[0].first_frame.rows[0].value[0].value[0].number_value
> {code}
> The {{value\[0\].value\[0\]}} is strange. Looking at the protobuf definition,
> it seems like both {{ColumnValue}} and {{TypedValue}} are repeated which is
> causing this. Only one of them should be repeated, not both. This creates the
> equivalent of a 2dim array inside each row instead of just a 1dim array.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1040) ColumnValue and TypedValue are unnecessarily both repeated
[
https://issues.apache.org/jira/browse/CALCITE-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1040.
-
Resolution: Fixed
Fixed in
https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=942693e67d1916264c98e0e803040e7f1f4311e3
Took the high path and made sure that, when present, we still do the same
(busted) parsing on the protobuf. This should make sure that we don't break 1.6
clients talking to 1.5 servers (the big reason we went protobuf to start).
Included tests for the 'old style' records, as well as added some arrays being
serialized/deserialized to make sure they were still working correctly.
Docs also included (will probably just wait for the 1.6.0 release to happen
instead of updating immediately). {{scalar_value}} will be set when the column
is a scalar, and {{array_value}} when it's an array.
> ColumnValue and TypedValue are unnecessarily both repeated
> --
>
> Key: CALCITE-1040
> URL: https://issues.apache.org/jira/browse/CALCITE-1040
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Carter Shanklin
>Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> [~cartershanklin] sent me some nice notes from working on a Python interface
> to the Phoenix QueryServer. He saw this strange thing in the code he had to
> write:
> {code}
> count = response.results[0].first_frame.rows[0].value[0].value[0].number_value
> {code}
> The {{value\[0\].value\[0\]}} is strange. Looking at the protobuf definition,
> it seems like both {{ColumnValue}} and {{TypedValue}} are repeated which is
> causing this. Only one of them should be repeated, not both. This creates the
> equivalent of a 2dim array inside each row instead of just a 1dim array.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1050) Avatica can't serialize java.sql.Array
[
https://issues.apache.org/jira/browse/CALCITE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094672#comment-15094672
]
Josh Elser commented on CALCITE-1050:
-
Thanks for writing this up [~lukaslalinsky]. This is a great example. I see
what you mean now.
On the "query results" side of things, we have {{Frame}} which which contains a
{{List}} of {{rows}}. For an array, the element in the {{rows}} would
be a {{List}} itself, which triggers it. I'm guessing that it was just missing
on this side.
Let me start by writing some tests to work through this. Thanks again for the
bug report.
> Avatica can't serialize java.sql.Array
> --
>
> Key: CALCITE-1050
> URL: https://issues.apache.org/jira/browse/CALCITE-1050
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Lukas Lalinsky
>Assignee: Josh Elser
>
> As far as I can see, there is no way to serialize arrays in the Avatica RPC.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1040) ColumnValue and TypedValue are unnecessarily both repeated
[
https://issues.apache.org/jira/browse/CALCITE-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094899#comment-15094899
]
Josh Elser commented on CALCITE-1040:
-
Ack, thanks for the catch! I can amend if you'd like?
> ColumnValue and TypedValue are unnecessarily both repeated
> --
>
> Key: CALCITE-1040
> URL: https://issues.apache.org/jira/browse/CALCITE-1040
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Carter Shanklin
>Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> [~cartershanklin] sent me some nice notes from working on a Python interface
> to the Phoenix QueryServer. He saw this strange thing in the code he had to
> write:
> {code}
> count = response.results[0].first_frame.rows[0].value[0].value[0].number_value
> {code}
> The {{value\[0\].value\[0\]}} is strange. Looking at the protobuf definition,
> it seems like both {{ColumnValue}} and {{TypedValue}} are repeated which is
> causing this. Only one of them should be repeated, not both. This creates the
> equivalent of a 2dim array inside each row instead of just a 1dim array.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1040) ColumnValue and TypedValue are unnecessarily both repeated
[
https://issues.apache.org/jira/browse/CALCITE-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094899#comment-15094899
]
Josh Elser edited comment on CALCITE-1040 at 1/12/16 8:42 PM:
--
Ack, thanks for the catch! I can push a change if you'd like?
was (Author: elserj):
Ack, thanks for the catch! I can amend if you'd like?
> ColumnValue and TypedValue are unnecessarily both repeated
> --
>
> Key: CALCITE-1040
> URL: https://issues.apache.org/jira/browse/CALCITE-1040
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Carter Shanklin
>Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> [~cartershanklin] sent me some nice notes from working on a Python interface
> to the Phoenix QueryServer. He saw this strange thing in the code he had to
> write:
> {code}
> count = response.results[0].first_frame.rows[0].value[0].value[0].number_value
> {code}
> The {{value\[0\].value\[0\]}} is strange. Looking at the protobuf definition,
> it seems like both {{ColumnValue}} and {{TypedValue}} are repeated which is
> causing this. Only one of them should be repeated, not both. This creates the
> equivalent of a 2dim array inside each row instead of just a 1dim array.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1053) Test occasionally hanging around use of ReflectiveRelMetadataProvider
Josh Elser created CALCITE-1053:
---
Summary: Test occasionally hanging around use of
ReflectiveRelMetadataProvider
Key: CALCITE-1053
URL: https://issues.apache.org/jira/browse/CALCITE-1053
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Josh Elser
Assignee: Julian Hyde
I've started seeing some tests (JdbcTest and JdbcFrontLinqBackTest) in
calcite-core hanging now and again:
{noformat}
"pool-1-thread-1" prio=5 tid=0x7fd50611e800 nid=0x5103 runnable
[0x000115b81000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:465)
at java.util.HashMap.get(HashMap.java:417)
at
org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:289)
at
org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
at
org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
at
org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
at
org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
at
org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
at
org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
- locked <0x0007e1287590> (a
com.google.common.cache.LocalCache$StrongEntry)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
at
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
at
org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
at org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
{noformat}
{noformat}
"pool-1-thread-6" prio=5 tid=0x7fd50684c000 nid=0x5d03 runnable
[0x000116193000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.put(HashMap.java:494)
at
org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:292)
at
org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
at
org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
at
org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
at
org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
at
org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
- locked <0x0007a0fa41a0> (a
com.google.common.cache.LocalCache$StrongEntry)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
at
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
at
org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
at org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15095176#comment-15095176
]
Josh Elser commented on CALCITE-1052:
-
bq. I'll try updating Phoenix and Calcite to their most recent snapshots and
re-running to check for a regression
Just updated Phoenix and Calcite and am still not seeing this.
bq. If you can create a test case which shows this actually happening, that
would extremely helpful
I should also say that anything I can run to reproduce this would work. It does
not have to be within the confines of a unit test.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
>
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15095098#comment-15095098
]
Josh Elser commented on CALCITE-1052:
-
I've hacked together a little script locally based on what you said here:
{noformat}
==> create_integer_table.sql <==
drop table if exists integer_table;
create table integer_table (id integer not null primary key, column1 integer);
UPSERT INTO INTEGER_TABLE VALUES(1, 1);
UPSERT INTO INTEGER_TABLE VALUES(2, 2);
UPSERT INTO INTEGER_TABLE VALUES(3, 3);
==> create_string_table.sql <==
drop table if exists varchar_table;
create table varchar_table (id integer not null primary key, column1
varchar(50));
UPSERT INTO VARCHAR_TABLE VALUES(1, 'str_1');
UPSERT INTO VARCHAR_TABLE VALUES(2, 'str_2');
UPSERT INTO VARCHAR_TABLE VALUES(3, 'str_3');
{noformat}
I inserted 50k records this way (upserts 4 through 4 omitted for obv
reasons).
I then ran two loops querying for records in the tables via sqlline-thin.py:
{noformat}
==> query_integer.sql <==
SELECT column1 FROM INTEGER_TABLE where id = 5000;
SELECT column1 FROM INTEGER_TABLE where id = 5000;
SELECT column1 FROM INTEGER_TABLE where id = 5000;
SELECT column1 FROM INTEGER_TABLE where id = 5000;
SELECT column1 FROM INTEGER_TABLE where id = 5000;
...
==> query_string.sql <==
SELECT column1 FROM VARCHAR_TABLE where id = 5000;
SELECT column1 FROM VARCHAR_TABLE where id = 5000;
SELECT column1 FROM VARCHAR_TABLE where id = 5000;
SELECT column1 FROM VARCHAR_TABLE where id = 5000;
SELECT column1 FROM VARCHAR_TABLE where id = 5000;
...
{noformat}
{noformat}
while true; do /usr/local/lib/phoenix/bin/sqlline-thin.py ~/query_string.sql;
done
{noformat}
{noformat}
while true; do /usr/local/lib/phoenix/bin/sqlline-thin.py ~/query_integer.sql;
done
{noformat}
Given what you described, [~kliew], I should expected to see "5000" showing up
while querying VARCHAR_TABLE and "str_5000" while querying INTEGER_TABLE (or
some errors casting "str_5000" into an integer). However, I did not see this.
I'll try updating Phoenix and Calcite to their most recent snapshots and
re-running to check for a regression, but I am not anticipating seeing what you
describe.
If you can create a test case which shows this actually happening, that would
extremely helpful. Right now, I can only assume that for your own driver, you
did not create unique connectionIDs. I'm still baffled about seeing this with
the JDBC driver as you said though.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
>
[jira] [Commented] (CALCITE-1044) Quirky handling of PrepareAndExecuteRequests maxRowCount attribute
[
https://issues.apache.org/jira/browse/CALCITE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15095210#comment-15095210
]
Josh Elser commented on CALCITE-1044:
-
[~julianhyde] can I get your opinion here? I thought it was silly that we would
accept a maxRowCount=0 on the server for a query, but I do see that we have a
test for that specific case.
Is there a reason that we should retain this functionality?
> Quirky handling of PrepareAndExecuteRequests maxRowCount attribute
> --
>
> Key: CALCITE-1044
> URL: https://issues.apache.org/jira/browse/CALCITE-1044
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Carter Shanklin
>Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> Another good find sent to me by [~cartershanklin].
> He noticed when using the Protobuf wire API directly, provided a value of 0
> for {{maxRowCount}} in a {{PrepareAndExecuteRequest}} resulted in no values
> being returned.
> I dug around a little and found this little tweak done:
> {panel:title=AvaticaStatement.java}
> {code}
> protected void executeInternal(String sql) throws SQLException {
> // reset previous state before moving forward.
> this.updateCount = -1;
> try {
> // In JDBC, maxRowCount = 0 means no limit; in prepare it means LIMIT 0
> final long maxRowCount1 = maxRowCount <= 0 ? -1 : maxRowCount;
> for (int i = 0; i < connection.maxRetriesPerExecute; i++) {
> try {
> Meta.ExecuteResult x =
> connection.prepareAndExecuteInternal(this, sql, maxRowCount1);
> {code}
> {panel}
> It would be nice to also do this correction on the server side to get this
> behavior since our wire API so closely matches the JDBC API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1049) SQLException not correctly propagated
[
https://issues.apache.org/jira/browse/CALCITE-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092622#comment-15092622
]
Josh Elser commented on CALCITE-1049:
-
I think your assessment is right, [~lukaslalinsky]. I remember I stubbed out
the necessary information, but wasn't positive that all of the paths where we
now catch an RTE and turn it into an ErrorResponse are properly caught. It
seems like you definitely found one :)
> SQLException not correctly propagated
> -
>
> Key: CALCITE-1049
> URL: https://issues.apache.org/jira/browse/CALCITE-1049
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Lukas Lalinsky
>Assignee: Julian Hyde
>
> When using the Phoenix (master) and it raises a SQLException, this is
> returned from the Avatica RPC server:
> {code}
> {
> "response":"error",
> "exceptions":[
> "java.lang.RuntimeException: ERROR 202 (22012): Divide by zero.\n"
> "\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:651)\n"
> "\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.prepareAndExecute(JdbcMeta.java:715)\n"
> "\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:179)\n"
> "\tat
> org.apache.calcite.avatica.remote.Service$PrepareAndExecuteRequest.accept(Service.java:1049)\n"
> "\tat
> org.apache.calcite.avatica.remote.Service$PrepareAndExecuteRequest.accept(Service.java:1023)\n"
> "\tat
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:100)\n"
> "\tat
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n"
> "\tat
> org.apache.calcite.avatica.server.AvaticaHandler.handle(AvaticaHandler.java:68)\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)\n"
> ],
> "errorMessage":"ERROR 202 (22012): Divide by zero.",
> "errorCode":-1,
> "sqlState":"0",
> "severity":"UNKNOWN"
> }
> {code}
> The SQLException is translated to RuntimeException and the errorCode and
> sqlState fields are set to "unknown" values, even though the codes were
> originally set in the SQLException.
> I'd expect that
> https://github.com/apache/calcite/blob/calcite-1.5.0/avatica-server/src/main/java/org/apache/calcite/avatica/jdbc/JdbcMeta.java#L645
> would have a special case for SQLException and translate it to
> AvaticaRuntimeException. I'm not sure if that is the correct solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1263) Case-insensitive match and null default value for enum properties
[
https://issues.apache.org/jira/browse/CALCITE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321206#comment-15321206
]
Josh Elser commented on CALCITE-1263:
-
Wow, sorry, I totally missed your ping on this. So sorry. We can look into a
1.8.1 if you'd like with this one.
> Case-insensitive match and null default value for enum properties
> -
>
> Key: CALCITE-1263
> URL: https://issues.apache.org/jira/browse/CALCITE-1263
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: next
>
>
> In ConnectionConfigImpl, we allow properties based on enum classes. The
> getEnum method throws "Required property 'name' not specified" if the default
> value is null, but it should not; we should allow enum properties whose
> default value is null.
> Also, when resolving an enum property we should check the exact string first,
> then look for case-insensitive matches. This will help if people write
> 'p=foo' if 'p' is a property of type enum { FOO, BAZ }.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1263) Case-insensitive match and null default value for enum properties
[
https://issues.apache.org/jira/browse/CALCITE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321207#comment-15321207
]
Josh Elser commented on CALCITE-1263:
-
Wow, sorry, I totally missed your ping on this. So sorry. We can look into a
1.8.1 if you'd like with this one.
> Case-insensitive match and null default value for enum properties
> -
>
> Key: CALCITE-1263
> URL: https://issues.apache.org/jira/browse/CALCITE-1263
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: next
>
>
> In ConnectionConfigImpl, we allow properties based on enum classes. The
> getEnum method throws "Required property 'name' not specified" if the default
> value is null, but it should not; we should allow enum properties whose
> default value is null.
> Also, when resolving an enum property we should check the exact string first,
> then look for case-insensitive matches. This will help if people write
> 'p=foo' if 'p' is a property of type enum { FOO, BAZ }.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CALCITE-1263) Case-insensitive match and null default value for enum properties
[
https://issues.apache.org/jira/browse/CALCITE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1263:
Comment: was deleted
(was: Wow, sorry, I totally missed your ping on this. So sorry. We can look
into a 1.8.1 if you'd like with this one.)
> Case-insensitive match and null default value for enum properties
> -
>
> Key: CALCITE-1263
> URL: https://issues.apache.org/jira/browse/CALCITE-1263
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: next
>
>
> In ConnectionConfigImpl, we allow properties based on enum classes. The
> getEnum method throws "Required property 'name' not specified" if the default
> value is null, but it should not; we should allow enum properties whose
> default value is null.
> Also, when resolving an enum property we should check the exact string first,
> then look for case-insensitive matches. This will help if people write
> 'p=foo' if 'p' is a property of type enum { FOO, BAZ }.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1263) Case-insensitive match and null default value for enum properties
[
https://issues.apache.org/jira/browse/CALCITE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321220#comment-15321220
]
Josh Elser commented on CALCITE-1263:
-
https://github.com/apache/calcite/pull/240 looks good to me. If you'd like it
to go into a 1.8.1, feel free to land it in branch-avatica-1.8 as well as
master; otherwise, it'll hit avatica 1.9.0.
> Case-insensitive match and null default value for enum properties
> -
>
> Key: CALCITE-1263
> URL: https://issues.apache.org/jira/browse/CALCITE-1263
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: next
>
>
> In ConnectionConfigImpl, we allow properties based on enum classes. The
> getEnum method throws "Required property 'name' not specified" if the default
> value is null, but it should not; we should allow enum properties whose
> default value is null.
> Also, when resolving an enum property we should check the exact string first,
> then look for case-insensitive matches. This will help if people write
> 'p=foo' if 'p' is a property of type enum \{ FOO, BAZ \}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1248) Release Avatica 1.8
[ https://issues.apache.org/jira/browse/CALCITE-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1248. - Resolution: Fixed The extra commits that have come in while releasing: 2bee6ef Reorganize release notes/news for avatica 1.8.0 600f615 Bump avatica to 1.9.0-SNAPSHOT 6c633cf Prevent an additional run of the tests > Release Avatica 1.8 > --- > > Key: CALCITE-1248 > URL: https://issues.apache.org/jira/browse/CALCITE-1248 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > Parent issue to track things to do for this release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1286) Create self-contained test-harness for TCK
Josh Elser created CALCITE-1286: --- Summary: Create self-contained test-harness for TCK Key: CALCITE-1286 URL: https://issues.apache.org/jira/browse/CALCITE-1286 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.9.0 Should make a Vagrant VM or a Docker image which is capable of automatically running the Avatica TCK. Ideally, running the TCK should be as simple as a single command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1287) Potential wire compatibility issue with binary data
[
https://issues.apache.org/jira/browse/CALCITE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15325331#comment-15325331
]
Josh Elser commented on CALCITE-1287:
-
Added the TCK test in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=113a034ec1689dd8313af5d2f2d2431f1e666eaa
Will wait to hear back from Kevin before closing this as cannot-repro. He might
have some critical details.
> Potential wire compatibility issue with binary data
> ---
>
> Key: CALCITE-1287
> URL: https://issues.apache.org/jira/browse/CALCITE-1287
> Project: Calcite
> Issue Type: Test
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Was chatting with [~kliew] today who mentioned that he thought there might be
> an issue with the wire-protocol with binary data ({{TypedValue.BYTE_STRING}}).
> avatica-1.8.0 did contain a change to how binary data was sent using
> protobufs (reported by [~francischuang] in CALCITE-1209, ultimately fixed in
> CALCITE-1103), but I believe this was done in a backwards compatible way.
> I just added a test to the TCK which shows that it is compatible with 1.6.0
> and 1.7.1, but maybe there is an edge condition I'm over looking (or the Java
> driver is masking).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1287) Potential wire compatibility issue with binary data
Josh Elser created CALCITE-1287:
---
Summary: Potential wire compatibility issue with binary data
Key: CALCITE-1287
URL: https://issues.apache.org/jira/browse/CALCITE-1287
Project: Calcite
Issue Type: Test
Components: avatica
Affects Versions: avatica-1.8.0
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.9.0
Was chatting with [~kliew] today who mentioned that he thought there might be
an issue with the wire-protocol with binary data ({{TypedValue.BYTE_STRING}}).
avatica-1.8.0 did contain a change to how binary data was sent using protobufs
(reported by [~francischuang] in CALCITE-1209, ultimately fixed in
CALCITE-1103), but I believe this was done in a backwards compatible way.
I just added a test to the TCK which shows that it is compatible with 1.6.0 and
1.7.1, but maybe there is an edge condition I'm over looking (or the Java
driver is masking).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1282) Avatica will only accept SPNEGO-authenticated clients from the same realm as the server's principal
[
https://issues.apache.org/jira/browse/CALCITE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1282.
-
Resolution: Fixed
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=6000c9e7c24d487517df1f93a3a174e38821cdae
> Avatica will only accept SPNEGO-authenticated clients from the same realm as
> the server's principal
> ---
>
> Key: CALCITE-1282
> URL: https://issues.apache.org/jira/browse/CALCITE-1282
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> When setting up the Jetty security Constraint class, Jetty treats Kerberos
> realms as "roles". When configuring allowed users to Jetty with some
> constraint, you have to set what roles (realms) are allowed.
> Presently, Avatica just sets the realm of the server's principal as allowed,
> which means that in some multi-realm KDC (or cross-domain MIT KRB+Active
> Directory) setup, users from the other realm which should be allowed are
> denied.
> Even better, Jetty's syntax for {{\*}} for allowing any role (realm) doesn't
> actually work. Their logic in 9.2.15 for {{ConstraintSecurityHandler}}
> appears broken:
> {code}
> //handle * role constraint
> if (roleInfo.isAnyRole() && request.getUserPrincipal() != null &&
> isUserInRole)
> {
> return true;
> }
> {code}
> The above check should let users through with any role when {{isAnyRole()}}
> returns true, but the final {{isUserInRole}} check requires that the role is
> explicitly listed in the list of allowedRoles.
> As such, we're going to need to expose an API which allows users to set a
> list of allowed realms since Jetty is busted to make Kerberos authentication
> actually work correctly.
> Thanks to [~kliew] for bringing this one to my attention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1291) Incorrect formatting from Avatica in sqlline's table outputformat
Josh Elser created CALCITE-1291:
---
Summary: Incorrect formatting from Avatica in sqlline's table
outputformat
Key: CALCITE-1291
URL: https://issues.apache.org/jira/browse/CALCITE-1291
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.9.0
{noformat}
0: jdbc:phoenix:thin:url=http://localhost:876> select * from STR_VIEW;
+--+--++
|PK| VAL
|LONG_VALUE |
+--+--++
| ASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDF | value1
| valuevaluevaluevalueva |
+--+--++
1 row selected (0.025 seconds)
{noformat}
{noformat}
0: jdbc:phoenix:localhost:2181:/hbase-1.2> select * from STR_VIEW;
+---+-+-+
|PK | VAL |
LONG_VALUE |
+---+-+-+
| ASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDFASDF | value1 |
valuevaluevaluevaluevaluevaluevaluevaluevaluevalue |
+---+-+-+
1 row selected (0.058 seconds)
{noformat}
This is the difference between using Apache Phoenix's avatica client and the
normal client and sqlline 1.1.9. With {{!outputformat table}} above, we can see
the difference in these two clients, while {{!outputformat xmlattr}} shows the
complete (and expected) values.
It seems like some column metadata is just not being properly sent by PQS (at
least that's my hunch). The data is present in the results, just not rendered
properly. I'll have to look into what sqlline pulls for the column width and
figure out if PQS is sending that properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1287) Potential wire compatibility issue with binary data
[
https://issues.apache.org/jira/browse/CALCITE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1287.
-
Resolution: Cannot Reproduce
Test was added, but original problem report was not reproducible.
> Potential wire compatibility issue with binary data
> ---
>
> Key: CALCITE-1287
> URL: https://issues.apache.org/jira/browse/CALCITE-1287
> Project: Calcite
> Issue Type: Test
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Was chatting with [~kliew] today who mentioned that he thought there might be
> an issue with the wire-protocol with binary data ({{TypedValue.BYTE_STRING}}).
> avatica-1.8.0 did contain a change to how binary data was sent using
> protobufs (reported by [~francischuang] in CALCITE-1209, ultimately fixed in
> CALCITE-1103), but I believe this was done in a backwards compatible way.
> I just added a test to the TCK which shows that it is compatible with 1.6.0
> and 1.7.1, but maybe there is an edge condition I'm over looking (or the Java
> driver is masking).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1287) Potential wire compatibility issue with binary data
[
https://issues.apache.org/jira/browse/CALCITE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328356#comment-15328356
]
Josh Elser commented on CALCITE-1287:
-
bq. Hi Josh, we have updated to a newer snapshot and are no longer seeing this
issue.
Great.
bq. We are sending parameters in base64 in string_value and receiving in
bytes_value since Phoenix 4.5. In the previous snapshot build, the server was
returning values with the `null` field set. After updating to the latest
snapshot, we are receiving data in both the string and bytes field and our test
cases pass.
Setting both string and bytes is what the server should be doing for backwards
compat (string is the b64 "unnecessary" way for old clients and bytes would be
the field to use going forward).
Thanks for getting back to me with your findings! I'll go ahead and close this
one as "Cannot Reproduce".
> Potential wire compatibility issue with binary data
> ---
>
> Key: CALCITE-1287
> URL: https://issues.apache.org/jira/browse/CALCITE-1287
> Project: Calcite
> Issue Type: Test
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Was chatting with [~kliew] today who mentioned that he thought there might be
> an issue with the wire-protocol with binary data ({{TypedValue.BYTE_STRING}}).
> avatica-1.8.0 did contain a change to how binary data was sent using
> protobufs (reported by [~francischuang] in CALCITE-1209, ultimately fixed in
> CALCITE-1103), but I believe this was done in a backwards compatible way.
> I just added a test to the TCK which shows that it is compatible with 1.6.0
> and 1.7.1, but maybe there is an edge condition I'm over looking (or the Java
> driver is masking).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1229) Restore API and Test API links to site
[ https://issues.apache.org/jira/browse/CALCITE-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327894#comment-15327894 ] Josh Elser commented on CALCITE-1229: - Just realized I never looked at this one like I said I would. Looking at it after the fact, things look good. The whitespace fix for news articles will be nice (I never dug into it to figure out where all that was coming from). > Restore API and Test API links to site > -- > > Key: CALCITE-1229 > URL: https://issues.apache.org/jira/browse/CALCITE-1229 > Project: Calcite > Issue Type: Bug > Components: site >Reporter: Julian Hyde >Assignee: Julian Hyde > Fix For: 1.9.0 > > > The site used to have links for API and Test API, but no longer has. It seems > to have happened in the [SVN > change|http://svn.apache.org/viewvc?view=revision=1739659] to fix > CALCITE-1203. > The other non-cosmetic change in that svn change, removing [~michaelmior] > from the committers list, was my fault. I had committed to svn but forgot to > push to git. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1254) Support PreparedStatement.executeLargeBatch
[
https://issues.apache.org/jira/browse/CALCITE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1254:
Priority: Blocker (was: Major)
> Support PreparedStatement.executeLargeBatch
> ---
>
> Key: CALCITE-1254
> URL: https://issues.apache.org/jira/browse/CALCITE-1254
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> In CALCITE-1128 we added support for PreparedStatement.executeBatch. This
> added ExecuteBatchResult with a field {{int[] updateCounts}}.
> I think that field should have been {{long[]}} instead. Elsewhere we have
> been converting update counts from {{int}} to {{long}}, in line with changes
> to the JDBC API.
> If changing this field from {{int[]}} to {{long[]}} will be a breaking change
> we should consider halting 1.8 to get this in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1254) Support PreparedStatement.executeLargeBatch
[
https://issues.apache.org/jira/browse/CALCITE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308769#comment-15308769
]
Josh Elser commented on CALCITE-1254:
-
Thanks again, Julian!
bq. Yes, I suppose that was a little contentious. I figured that if someone was
asking for at most N rows then clearly there could be no more than N rows in
the first frame. Given that cap, I can't imagine a scenario where an existing
client would see a change in behavior. My vote would be to clarify the
documentation of prepareAndExecute to state that maxRowsInFirstFrame is capped
by maxRowCount.
Great. I can do that.
bq. And by the way, don't use (int) to cast to int, use saturated cast, so that
2^32 becomes Integer.MAX_VALUE rather than 0, and importantly -1 remains -1.
Right you are again. I'll make a pass over the codebase. I think there might
have been some other instances of this.
> Support PreparedStatement.executeLargeBatch
> ---
>
> Key: CALCITE-1254
> URL: https://issues.apache.org/jira/browse/CALCITE-1254
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> In CALCITE-1128 we added support for PreparedStatement.executeBatch. This
> added ExecuteBatchResult with a field {{int[] updateCounts}}.
> I think that field should have been {{long[]}} instead. Elsewhere we have
> been converting update counts from {{int}} to {{long}}, in line with changes
> to the JDBC API.
> If changing this field from {{int[]}} to {{long[]}} will be a breaking change
> we should consider halting 1.8 to get this in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1254) Support PreparedStatement.executeLargeBatch
[
https://issues.apache.org/jira/browse/CALCITE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1254.
-
Resolution: Fixed
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=08c966b9828f534ba3d8d2ccf052de7d887c70ef.
Thanks to Julian for his help in getting this improved!
> Support PreparedStatement.executeLargeBatch
> ---
>
> Key: CALCITE-1254
> URL: https://issues.apache.org/jira/browse/CALCITE-1254
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> In CALCITE-1128 we added support for PreparedStatement.executeBatch. This
> added ExecuteBatchResult with a field {{int[] updateCounts}}.
> I think that field should have been {{long[]}} instead. Elsewhere we have
> been converting update counts from {{int}} to {{long}}, in line with changes
> to the JDBC API.
> If changing this field from {{int[]}} to {{long[]}} will be a breaking change
> we should consider halting 1.8 to get this in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1267) Point to release notes on website in README
Josh Elser created CALCITE-1267: --- Summary: Point to release notes on website in README Key: CALCITE-1267 URL: https://issues.apache.org/jira/browse/CALCITE-1267 Project: Calcite Issue Type: Task Components: avatica, site Reporter: Josh Elser Assignee: Josh Elser Priority: Trivial Fix For: avatica-1.8.0 bq. In my opinion, it would be nice if there were a README file saying "you have downloaded avatica version 1.8; the release notes are in file xxx". But by no means a show-stopper. We can easily point to the website in the README. Pretty trivial to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1267) Point to release notes on website in README
[ https://issues.apache.org/jira/browse/CALCITE-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1267. - Resolution: Fixed Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=ea25b7327e734f93acae85dc60f6188f852bed12 > Point to release notes on website in README > --- > > Key: CALCITE-1267 > URL: https://issues.apache.org/jira/browse/CALCITE-1267 > Project: Calcite > Issue Type: Task > Components: avatica, site >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: avatica-1.8.0 > > > bq. In my opinion, it would be nice if there were a README file saying "you > have downloaded avatica version 1.8; the release notes are in file xxx". But > by no means a show-stopper. > We can easily point to the website in the README. Pretty trivial to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1254) Support PreparedStatement.executeLargeBatch
[
https://issues.apache.org/jira/browse/CALCITE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307799#comment-15307799
]
Josh Elser commented on CALCITE-1254:
-
bq. OK, you're right. I was able to implement prepareAndExecuteBatch without a
PrepareCallback parameter. So, issue 2 is no longer an issue.
Great!
bq. Can you review, squash into your work and commit? (No need to retain my
commit as a separate commit.)
Will do.
> Support PreparedStatement.executeLargeBatch
> ---
>
> Key: CALCITE-1254
> URL: https://issues.apache.org/jira/browse/CALCITE-1254
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> In CALCITE-1128 we added support for PreparedStatement.executeBatch. This
> added ExecuteBatchResult with a field {{int[] updateCounts}}.
> I think that field should have been {{long[]}} instead. Elsewhere we have
> been converting update counts from {{int}} to {{long}}, in line with changes
> to the JDBC API.
> If changing this field from {{int[]}} to {{long[]}} will be a breaking change
> we should consider halting 1.8 to get this in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1258) JDK9 support
[ https://issues.apache.org/jira/browse/CALCITE-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332624#comment-15332624 ] Josh Elser commented on CALCITE-1258: - bq. I couldn't figure out what maven plugins to use. I can try to help out with this. Your branch up to date with your latest? > JDK9 support > > > Key: CALCITE-1258 > URL: https://issues.apache.org/jira/browse/CALCITE-1258 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > I notice that Travis now offers JDK9. Let's get Calcite building & running on > JDK9. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1300) AvaticaCommonsHttpClientImpl doesn't retry on HTTP/503
Josh Elser created CALCITE-1300: --- Summary: AvaticaCommonsHttpClientImpl doesn't retry on HTTP/503 Key: CALCITE-1300 URL: https://issues.apache.org/jira/browse/CALCITE-1300 Project: Calcite Issue Type: Bug Components: avatica Affects Versions: avatica-1.8.0 Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.9.0 In the original AvaticaHttpClient implementation, I had added some logic to retry when the client receives an HTTP/503 from the server. This was to make the client a little more resilient towards talking to an HTTP load balancer instead of directly to the Avatica server. Load balancers should send back an HTTP/503 when the backend server fails to respond -- the client should be able to retry this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1298) Consider removing Util.toString
[
https://issues.apache.org/jira/browse/CALCITE-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336274#comment-15336274
]
Josh Elser commented on CALCITE-1298:
-
Did a quick check to make sure that Joiner wasn't on the chopping block for
Guava (as they tend to liberally do). Sounds fine to me to replace.
> Consider removing Util.toString
> ---
>
> Key: CALCITE-1298
> URL: https://issues.apache.org/jira/browse/CALCITE-1298
> Project: Calcite
> Issue Type: Improvement
>Reporter: Michael Mior
>Assignee: Julian Hyde
>Priority: Minor
>
> {{Util.toString}} seems unnecessary in light of
> {{com.google.common.base.Joiner}}. There are ~16 total usages of this across
> the entire code base. One inside {{SubstitutionVisitor}} and the rest
> scattered around the Mongo, Cassandra, and Elasticsearch adapters. If there
> are no objections, I'll remove this and replace with {{Joiner}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096962#comment-15096962
]
Josh Elser commented on CALCITE-1052:
-
No, I take it back. Even then, a unique connection ID on the client should have
disallowed this.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
> System.out.println(column1);
> }
>
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096822#comment-15096822
]
Josh Elser commented on CALCITE-1052:
-
Ahh, good catch. I will experiment some more while you package things up.
Thanks.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
> System.out.println(column1);
> }
> }
> }
>
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096936#comment-15096936
]
Josh Elser commented on CALCITE-1052:
-
Actually, you may just be running into CALCITE-912. I'm trying to refresh
myself on how this previously worked.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
> System.out.println(column1);
>
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098450#comment-15098450
]
Josh Elser commented on CALCITE-1052:
-
[~kliew], I'm not having any success with your docker container so far. It
seems to hang before ever starting PQS.
Can you drop me an email? (see the addr on my JIRA acct).
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
>
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102167#comment-15102167
]
Josh Elser commented on CALCITE-1052:
-
bq. I did some reading and it looks like these errors are due to our driver
using JSON whereas newer versions of Phoenix use protocol buffers for
communication
No, you would never have gotten into that code if you sent JSON and the server
was expecting protobuf.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: phoenix-root-server.log, test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ('One','1');
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.INTEGER_TABLE VALUES ('Two',2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102464#comment-15102464
]
Josh Elser commented on CALCITE-1052:
-
Alright, I still can't reproduce what you say you're seeing, so have a look at
what I did.
Docker image: https://github.com/joshelser/docker-phoenix
Client repo: https://github.com/joshelser/phoenix-queryserver-jdbc-client
{{docker run -P -it joshelser/apache-phoenix}}
then, follow the instructions on the Github page for the client repo using the
URL for the QueryServer (whose port should get mapped out of the docker
container). For some reason, I had to explicitly set the SERIALIZATION to be
protobuf in the URL (the {{;serialization=PROTOBUF}} bit). I thought the thin
driver should be defaulting to that already but perhaps I'm mistaken.
Let me know if this works for you.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: phoenix-root-server.log, test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ('One','1');
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.INTEGER_TABLE VALUES ('Two',2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
>
[jira] [Commented] (CALCITE-1053) Test occasionally hanging around use of ReflectiveRelMetadataProvider
[
https://issues.apache.org/jira/browse/CALCITE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15096498#comment-15096498
]
Josh Elser commented on CALCITE-1053:
-
Thanks for fixing [~vladimirsitnikov].
https://github.com/apache/calcite/commit/fe91d46761f460927b21ef334fee5e686b54e397
Please don't forget to add the JIRA issue when you make a commit in the future
(e.g. "[CALCITE-1053] Fix CPU spin in ReflectiveRelMetadataProvider.apply ->
HashMap.get")
> Test occasionally hanging around use of ReflectiveRelMetadataProvider
> -
>
> Key: CALCITE-1053
> URL: https://issues.apache.org/jira/browse/CALCITE-1053
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Josh Elser
>Assignee: Vladimir Sitnikov
> Fix For: 1.6.0
>
>
> I've started seeing some tests (JdbcTest and JdbcFrontLinqBackTest) in
> calcite-core hanging now and again:
> {noformat}
> "pool-1-thread-1" prio=5 tid=0x7fd50611e800 nid=0x5103 runnable
> [0x000115b81000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:465)
> at java.util.HashMap.get(HashMap.java:417)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:289)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> - locked <0x0007e1287590> (a
> com.google.common.cache.LocalCache$StrongEntry)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
> at
> org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
> {noformat}
> {noformat}
> "pool-1-thread-6" prio=5 tid=0x7fd50684c000 nid=0x5d03 runnable
> [0x000116193000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.put(HashMap.java:494)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:292)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> - locked <0x0007a0fa41a0> (a
> com.google.common.cache.LocalCache$StrongEntry)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
> at
> org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
>
> {noformat}
--
This message was
[jira] [Updated] (CALCITE-1053) Test occasionally hanging around use of ReflectiveRelMetadataProvider
[
https://issues.apache.org/jira/browse/CALCITE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1053:
Fix Version/s: 1.6.0
> Test occasionally hanging around use of ReflectiveRelMetadataProvider
> -
>
> Key: CALCITE-1053
> URL: https://issues.apache.org/jira/browse/CALCITE-1053
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Josh Elser
>Assignee: Vladimir Sitnikov
> Fix For: 1.6.0
>
>
> I've started seeing some tests (JdbcTest and JdbcFrontLinqBackTest) in
> calcite-core hanging now and again:
> {noformat}
> "pool-1-thread-1" prio=5 tid=0x7fd50611e800 nid=0x5103 runnable
> [0x000115b81000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:465)
> at java.util.HashMap.get(HashMap.java:417)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:289)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> - locked <0x0007e1287590> (a
> com.google.common.cache.LocalCache$StrongEntry)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
> at
> org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
> {noformat}
> {noformat}
> "pool-1-thread-6" prio=5 tid=0x7fd50684c000 nid=0x5d03 runnable
> [0x000116193000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.put(HashMap.java:494)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:292)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> - locked <0x0007a0fa41a0> (a
> com.google.common.cache.LocalCache$StrongEntry)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
> at
> org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1053) Test occasionally hanging around use of ReflectiveRelMetadataProvider
[
https://issues.apache.org/jira/browse/CALCITE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1053:
Assignee: Vladimir Sitnikov (was: Julian Hyde)
> Test occasionally hanging around use of ReflectiveRelMetadataProvider
> -
>
> Key: CALCITE-1053
> URL: https://issues.apache.org/jira/browse/CALCITE-1053
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Josh Elser
>Assignee: Vladimir Sitnikov
>
> I've started seeing some tests (JdbcTest and JdbcFrontLinqBackTest) in
> calcite-core hanging now and again:
> {noformat}
> "pool-1-thread-1" prio=5 tid=0x7fd50611e800 nid=0x5103 runnable
> [0x000115b81000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:465)
> at java.util.HashMap.get(HashMap.java:417)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:289)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> - locked <0x0007e1287590> (a
> com.google.common.cache.LocalCache$StrongEntry)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
> at
> org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
> {noformat}
> {noformat}
> "pool-1-thread-6" prio=5 tid=0x7fd50684c000 nid=0x5d03 runnable
> [0x000116193000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.put(HashMap.java:494)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:292)
> at
> org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.apply(ReflectiveRelMetadataProvider.java:278)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.ChainedRelMetadataProvider.apply(ChainedRelMetadataProvider.java:63)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:57)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl$2.load(MetadataFactoryImpl.java:54)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> - locked <0x0007a0fa41a0> (a
> com.google.common.cache.LocalCache$StrongEntry)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at
> org.apache.calcite.rel.metadata.MetadataFactoryImpl.query(MetadataFactoryImpl.java:71)
> at
> org.apache.calcite.rel.AbstractRelNode.metadata(AbstractRelNode.java:296)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getNonCumulativeCost(RelMetadataQuery.java:140)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105581#comment-15105581 ] Josh Elser commented on CALCITE-669: Anyone have opinions on how to map the 3 levels from java logging to the 2 which slf4j provide? Java Logging * FINE * FINER * FINEST Slf4j Levels * DEBUG * TRACE What kind of breakdown would we want here? DEBUG == (FINE and FINER), TRACE == FINEST? DEBUG == FINE, TRACE == (FINER and FINEST)? > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105501#comment-15105501 ] Josh Elser commented on CALCITE-669: Thanks for the reminder. Will look at the docs. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-669: -- Assignee: Josh Elser (was: Julian Hyde) > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105490#comment-15105490 ] Josh Elser commented on CALCITE-669: Going to work on swapping this out. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-669: --- Fix Version/s: 1.7.0 > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15105768#comment-15105768 ] Josh Elser commented on CALCITE-669: I suppose "FINE" could also be put at the INFO level :). It doesn't seem like we have much coming out at that level anyways. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1300) AvaticaCommonsHttpClientImpl doesn't retry on HTTP/503
[ https://issues.apache.org/jira/browse/CALCITE-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1300. - Resolution: Fixed Resolved in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=3b5d88e6a717600f2c7c282ae7319875866017ea > AvaticaCommonsHttpClientImpl doesn't retry on HTTP/503 > -- > > Key: CALCITE-1300 > URL: https://issues.apache.org/jira/browse/CALCITE-1300 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.8.0 >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > In the original AvaticaHttpClient implementation, I had added some logic to > retry when the client receives an HTTP/503 from the server. > This was to make the client a little more resilient towards talking to an > HTTP load balancer instead of directly to the Avatica server. Load balancers > should send back an HTTP/503 when the backend server fails to respond -- the > client should be able to retry this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141012#comment-15141012
]
Josh Elser edited comment on CALCITE-553 at 2/10/16 3:36 PM:
-
-Oh, I think this is actually a Maven bug. The documentation definitely says
that this should work, and upgrading to 3.3.9 does fix it.-
-I will find the necessary minimum version to get this working and add a maven
min-version enforcer statement for this.-
Argh, apparently it was just circumstantial.
was (Author: elserj):
Oh, I think this is actually a Maven bug. The documentation definitely says
that this should work, and upgrading to 3.3.9 does fix it.
I will find the necessary minimum version to get this working and add a maven
min-version enforcer statement for this.
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Josh Elser
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141012#comment-15141012
]
Josh Elser commented on CALCITE-553:
Oh, I think this is actually a Maven bug. The documentation definitely says
that this should work, and upgrading to 3.3.9 does fix it.
I will find the necessary minimum version to get this working and add a maven
min-version enforcer statement for this.
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Vladimir Sitnikov
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Moved] (CALCITE-1081) Need Detailed Documentation for HTTP Avatica Support
[
https://issues.apache.org/jira/browse/CALCITE-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser moved PHOENIX-2660 to CALCITE-1081:
--
Affects Version/s: (was: 4.7.0)
(was: 4.6.0)
Workflow: jira (was: no-reopen-closed, patch-avail)
Key: CALCITE-1081 (was: PHOENIX-2660)
Project: Calcite (was: Phoenix)
> Need Detailed Documentation for HTTP Avatica Support
>
>
> Key: CALCITE-1081
> URL: https://issues.apache.org/jira/browse/CALCITE-1081
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Steve T
>
> I was unable to find any documentation on how to use the Avatica features. I
> was not even able to find them on the Avatica site. Would be great if
> Phoenix had a least a few examples of how to us the feature such as the one I
> wrote below. It took me 2-3 days to figure it out with the help of
> u...@phoenix.apache.org . Should have only taken about 15 minutes. Granted,
> the JSON format is outdated in recent versions, but you get the idea. I
> couldn't even figure out which requests were required and what sequence they
> had to be in.
> {code:title=example_upsert.sh|borderStyle=solid}
> #!/bin/bash
> curl -XPOST -H 'Content-Type application/json; charset=UTF-8' -d
> '{"connectionId": "----", "request":
> "openConnection"}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": null, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": true, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"createStatement\",\"connectionId\":\"----\"}"
> http://10.0.100.28:8765/
> echo
> echo Enter the statementId:
> read statement_id
> echo
> echo Enter the value:
> read value
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL2',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"closeStatement\",\"connectionId\":\"----\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "closeConnection"}' http://10.0.100.28:8765/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CALCITE-1081) Need Detailed Documentation for HTTP Avatica Support
[
https://issues.apache.org/jira/browse/CALCITE-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1081:
---
Assignee: Josh Elser
> Need Detailed Documentation for HTTP Avatica Support
>
>
> Key: CALCITE-1081
> URL: https://issues.apache.org/jira/browse/CALCITE-1081
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Steve T
>Assignee: Josh Elser
>
> I was unable to find any documentation on how to use the Avatica features. I
> was not even able to find them on the Avatica site. Would be great if
> Phoenix had a least a few examples of how to us the feature such as the one I
> wrote below. It took me 2-3 days to figure it out with the help of
> u...@phoenix.apache.org . Should have only taken about 15 minutes. Granted,
> the JSON format is outdated in recent versions, but you get the idea. I
> couldn't even figure out which requests were required and what sequence they
> had to be in.
> {code:title=example_upsert.sh|borderStyle=solid}
> #!/bin/bash
> curl -XPOST -H 'Content-Type application/json; charset=UTF-8' -d
> '{"connectionId": "----", "request":
> "openConnection"}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": null, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": true, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"createStatement\",\"connectionId\":\"----\"}"
> http://10.0.100.28:8765/
> echo
> echo Enter the statementId:
> read statement_id
> echo
> echo Enter the value:
> read value
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL2',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"closeStatement\",\"connectionId\":\"----\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "closeConnection"}' http://10.0.100.28:8765/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Moved] (CALCITE-1082) CORS Support for Avatica Requests on Phoenix Query Server
[
https://issues.apache.org/jira/browse/CALCITE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser moved PHOENIX-2661 to CALCITE-1082:
--
Affects Version/s: (was: 4.7.0)
(was: 4.6.0)
Workflow: jira (was: no-reopen-closed, patch-avail)
Key: CALCITE-1082 (was: PHOENIX-2661)
Project: Calcite (was: Phoenix)
> CORS Support for Avatica Requests on Phoenix Query Server
> -
>
> Key: CALCITE-1082
> URL: https://issues.apache.org/jira/browse/CALCITE-1082
> Project: Calcite
> Issue Type: New Feature
>Reporter: Steve T
>Priority: Minor
>
> It would be super cool if I could write Javascript in a web page to
> read/write my Phoenix tables. I spend the last few days learning about CORS
> and browser security. I found out that what I am trying to accomplish cannot
> be readily done because the browser adds CORS headers (like
> {color:blue}{{Origin: }}{color}) and methods (like
> {color:blue}{{method: OPTIONS}}{color}) that are not supported by Phoenix
> Query Server.
> I do not know if this can be added on the Phoenix side or if it has to be
> added on the Avatica side, but for the time being I am trying the following
> to make it work:
> 1. Unconventional Javascript to remove the
> {color:blue}{{X-Requested-With}}{color} header in the request.
> 2. One line code change in Avatica's
> {color:blue}{{AvaticaJsonHandler.handle()}}{color} to add an
> {color:blue}{{Access-Control-Allow-Origin: *}}{color} header to the response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1082) CORS Support for Avatica Requests
[
https://issues.apache.org/jira/browse/CALCITE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1082:
Summary: CORS Support for Avatica Requests (was: CORS Support for Avatica
Requests on Phoenix Query Server)
> CORS Support for Avatica Requests
> -
>
> Key: CALCITE-1082
> URL: https://issues.apache.org/jira/browse/CALCITE-1082
> Project: Calcite
> Issue Type: New Feature
>Reporter: Steve T
>Priority: Minor
>
> It would be super cool if I could write Javascript in a web page to
> read/write my Phoenix tables. I spend the last few days learning about CORS
> and browser security. I found out that what I am trying to accomplish cannot
> be readily done because the browser adds CORS headers (like
> {color:blue}{{Origin: }}{color}) and methods (like
> {color:blue}{{method: OPTIONS}}{color}) that are not supported by Phoenix
> Query Server.
> I do not know if this can be added on the Phoenix side or if it has to be
> added on the Avatica side, but for the time being I am trying the following
> to make it work:
> 1. Unconventional Javascript to remove the
> {color:blue}{{X-Requested-With}}{color} header in the request.
> 2. One line code change in Avatica's
> {color:blue}{{AvaticaJsonHandler.handle()}}{color} to add an
> {color:blue}{{Access-Control-Allow-Origin: *}}{color} header to the response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1077) Separate Avatica from "core" Calcite build
Josh Elser created CALCITE-1077: --- Summary: Separate Avatica from "core" Calcite build Key: CALCITE-1077 URL: https://issues.apache.org/jira/browse/CALCITE-1077 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: 1.7.0 Uber-JIRA-issue for tracking the separation of Avatica from the rest of the Calcite build. Long term, Avatica can be a standalone project, but we're not there yet in terms of governance (enough people intimately involved). One thing we can do now is to separate Avatica from Calcite and begin "getting them used to" not being next to one another. DISCUSS thread: https://mail-archives.apache.org/mod_mbox/calcite-dev/201601.mbox/%3C56ABCCFF.3010205%40gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-553.
Resolution: Fixed
Double commit on this one; realized once I pushed that I needed to update the
website too.
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=a0b607ade51d2fcd6937f187da2d3691004c03d5
and
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=96fd5b7cf36f7893458fbbfc5d716f9202e8407c
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Josh Elser
> Fix For: next
>
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144077#comment-15144077
]
Josh Elser commented on CALCITE-553:
{{mvn clean verify}}
{noformat}
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 05:16 min
[INFO] Finished at: 2016-02-12T00:10:05-05:00
[INFO] Final Memory: 79M/623M
[INFO]
{noformat}
{{mvn verify -P'!generate-parser,!generate-version-properties'}}
{noformat}
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 04:24 min
[INFO] Finished at: 2016-02-12T00:17:07-05:00
[INFO] Final Memory: 49M/627M
[INFO]
{noformat}
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Josh Elser
> Fix For: next
>
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1082) CORS Support for Avatica Requests
[
https://issues.apache.org/jira/browse/CALCITE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139414#comment-15139414
]
Josh Elser commented on CALCITE-1082:
-
Moved this one too, [~brane2]. I've run into CORS before, I'm a little fuzzy.
Have you thought about the security implications of this? If we would set the
header, are there other things we'd have to worry about (in other words, do we
need an option to turn this on/off per user)?
> CORS Support for Avatica Requests
> -
>
> Key: CALCITE-1082
> URL: https://issues.apache.org/jira/browse/CALCITE-1082
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
>Reporter: Steve T
>Priority: Minor
>
> It would be super cool if I could write Javascript in a web page to
> read/write my Phoenix tables. I spend the last few days learning about CORS
> and browser security. I found out that what I am trying to accomplish cannot
> be readily done because the browser adds CORS headers (like
> {color:blue}{{Origin: }}{color}) and methods (like
> {color:blue}{{method: OPTIONS}}{color}) that are not supported by Phoenix
> Query Server.
> I do not know if this can be added on the Phoenix side or if it has to be
> added on the Avatica side, but for the time being I am trying the following
> to make it work:
> 1. Unconventional Javascript to remove the
> {color:blue}{{X-Requested-With}}{color} header in the request.
> 2. One line code change in Avatica's
> {color:blue}{{AvaticaJsonHandler.handle()}}{color} to add an
> {color:blue}{{Access-Control-Allow-Origin: *}}{color} header to the response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140408#comment-15140408
]
Josh Elser commented on CALCITE-553:
I think this is ultimately boiling down to the profile activation check
happening before the clean phase runs. The profile isn't activated because
core/target/generated-sources/fmpp/javacc/Parser.jj exists, the clean destroys
all of target, fmpp doesn't get re-run, and then the javacc plugin also skips
itself because its source directory (the fmpp output) doesn't exist.
I can understand the worth in trying to get incremental compliation and faster
builds, but it really bothers me when it comes at the cost of breaking the
expected semantics of the build tool. I'll see if there's some kind of trick I
can find to work around this, but, if I can't figure something out, I'm going
to suggest we remove the activation block (and run it all the time).
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Vladimir Sitnikov
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1085) NoopTimer#start should not create a new NoopContext for every invocation
[
https://issues.apache.org/jira/browse/CALCITE-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1085.
-
Resolution: Fixed
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=de7759112cea3deb8a1c75bcc43753adbe8648de
> NoopTimer#start should not create a new NoopContext for every invocation
>
>
> Key: CALCITE-1085
> URL: https://issues.apache.org/jira/browse/CALCITE-1085
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: next
>
>
> Just noticed that I forgot to make NoopTimer return a singleton NoopContext
> from {{#start}}. This is going to increase the burden for metrics for the
> noop case, potentially creating a lot of garbage on the heap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1086) Statement is unnecessarily sent from client in update (write) path
Josh Elser created CALCITE-1086:
---
Summary: Statement is unnecessarily sent from client in update
(write) path
Key: CALCITE-1086
URL: https://issues.apache.org/jira/browse/CALCITE-1086
Project: Calcite
Issue Type: Improvement
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Critical
Fix For: next
I've had my nose buried in profilers and Avatica evaluating the write
performance. Using Phoenix as the golden child, it was found that, compared to
HBase REST server (also doing updates over HTTP), Avatica was performing quite
a bit slower (2-3x).
The client was doing something like:
{code}
prepare()
for x in 0..1000:
for x in 0..1000:
execute()
end
commit()
end
{code}
One of the first big things that jumped out at me was that we were spending a
significant amount of time deserializing Meta.Signature (and all of its
internal classes: AvaticaParameter, ColumnMetaData, CursorFactory, Style, etc).
When we're ultimately doing a {{PreparedStatement.executeUpdate()}} inside
{{JdbcMeta.execute()}}, we completely ignore the Signature. This turns out to
be relatively significant WRT the entire cost of the execute. At the 99th
percentile, serialization was taking ~40% of the time of the entire execute
RPC. My hunch is that if we can drop the Statement from the client (when they
use executeUpdate(), anyways), we can get a nice reduction in update latency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-553:
---
Fix Version/s: next
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Josh Elser
> Fix For: next
>
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144021#comment-15144021
]
Josh Elser commented on CALCITE-553:
Alright, I have what I view as a fix here. We move away from the current broken
approach (broken, in the sense of what is expected of Maven projects), and move
the profiles that are necessary to make the incremental compilation stuff
working active by default with the ability to disable them. As such, this
should let those whom this is very important to still use benefit from it.
The following profiles can be disable on the command line to avoid the
re-generation {{generate-parser}} {{generate-version-properties}}. Or, in
context, {{mvn package -P'!generate-parser,!generate-version-properties'}}
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Josh Elser
> Fix For: next
>
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1079) Update website for Avatica
Josh Elser created CALCITE-1079: --- Summary: Update website for Avatica Key: CALCITE-1079 URL: https://issues.apache.org/jira/browse/CALCITE-1079 Project: Calcite Issue Type: Sub-task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: 1.7.0 * Centralize all of the avatica content into its own "directory" inside of the calcite website * Create history.md file for tracking avatica releases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1078) Move all Avatica module into a detached directory
Josh Elser created CALCITE-1078: --- Summary: Move all Avatica module into a detached directory Key: CALCITE-1078 URL: https://issues.apache.org/jira/browse/CALCITE-1078 Project: Calcite Issue Type: Sub-task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: 1.7.0 To decouple Avatica from the rest of Calcite, we need to restructure the location of the Maven modules and the pom structure. Let's move all of the avatica modules into an "avatica/" directory at the root of the Calcite repository. We should also directly use the Apache parent pom instead of the Calcite parent pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-642) Avatica server metrics
[ https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-642. Resolution: Fixed Merged in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=7e5710fc7459728a667659ea2b66895812ef839f > Avatica server metrics > -- > > Key: CALCITE-642 > URL: https://issues.apache.org/jira/browse/CALCITE-642 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser > Labels: avatica > Fix For: next > > > Along the same lines as CALCITE-641, avatica server should track some basic > metrics. We can expose them through a "standard" API (such as Hadoop metrics, > or Dropwizard metrics), and include them on some interval in the service log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-642) Avatica server metrics
[ https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122381#comment-15122381 ] Josh Elser commented on CALCITE-642: So this is what I'm thinking: * Remove all dropwizard API use in Avatica directly, create my own interfaces ala "avatica-metrics" * Implement interfaces in an "avatica-metrics-dropwizard-3" (or something -- need to figure out what/if-at-all is their compat statement) * Have calcite-avatica create two (shaded) artifacts: "calcite-avatica.jar" and "calcite-avatica-without-metrics.jar" (could also do a with-metrics instead of without-metrics but I'm being selfish and hoping the without-metrics jar would be less common) For those running in an AppServer (or some shared environment w/o classpath isolation), they can use the without-metrics jar and provide the version they want. We would also be able to provide bindings for other systems natively (if necessary). Hopefully, the common case would still be the single calcite-avatica.jar, but we wouldn't screw over those whose needs aren't satisfied. > Avatica server metrics > -- > > Key: CALCITE-642 > URL: https://issues.apache.org/jira/browse/CALCITE-642 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser > Labels: avatica > Fix For: next > > > Along the same lines as CALCITE-641, avatica server should track some basic > metrics. We can expose them through a "standard" API (such as Hadoop metrics, > or Dropwizard metrics), and include them on some interval in the service log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-642) Avatica server metrics
[
https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122284#comment-15122284
]
Josh Elser commented on CALCITE-642:
Thanks for taking a look, Julian.
bq. Change the commit description to make clear you're adding to Avatica
*server*. We don't need dependency bloat in the client.
So, this isn't entirely true. We have some code which is only intended to run
in the server, but lives in the "client" package, e.g. {{JsonHandler}} handles
the serialization into POJOs. The dropwizard-metrics artifact itself is only
110KB in size, ~100classes and the only provided reporter is an slf4j one
(suddenly the slf4j work becomes more important). Long term, I think having the
ability to use this metrics instrumentation to measure things in the client is
valuable as well (but is presently left as a "todo"). Looks like the
calcite-avatica jar is at ~3.5MB with these changes.
Is including this dependency in the calcite-avatica a deal-breaker for you?
Restructuring stuff for avatica has been on my radar (notably the splitting up
of Service and the POJOs), but I didn't want to try to tackle both of these at
once.
bq. Add a small section to http://calcite.apache.org/docs/avatica_overview.html
and add the package to the "structure" section
Ahh, thanks for the reminder. I meant to write up some docs for users too.
bq. Move the version number in pom.xml into the properties list (consistent
with what I did in CALCITE-999)
Will do.
> Avatica server metrics
> --
>
> Key: CALCITE-642
> URL: https://issues.apache.org/jira/browse/CALCITE-642
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Nick Dimiduk
>Assignee: Josh Elser
> Labels: avatica
> Fix For: next
>
>
> Along the same lines as CALCITE-641, avatica server should track some basic
> metrics. We can expose them through a "standard" API (such as Hadoop metrics,
> or Dropwizard metrics), and include them on some interval in the service log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-642) Avatica server metrics
[ https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122301#comment-15122301 ] Josh Elser commented on CALCITE-642: bq. I don't want to be a jerk about this Not at all! I'm just trying to make sure I understand the scope of the objection. bq. The client might be used in an environment (say an app server) that has an incompatible version of Dropwizard Let me play with this, we might be able to work around this the same way we did for protobuf (relocating the classes in the shaded jar). This is a bit dirtier since it's not self-contained like protobuf was (we expect users to have some interactions). Let me brainstorm some ideas. > Avatica server metrics > -- > > Key: CALCITE-642 > URL: https://issues.apache.org/jira/browse/CALCITE-642 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser > Labels: avatica > Fix For: next > > > Along the same lines as CALCITE-641, avatica server should track some basic > metrics. We can expose them through a "standard" API (such as Hadoop metrics, > or Dropwizard metrics), and include them on some interval in the service log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-642) Avatica server metrics
[ https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126841#comment-15126841 ] Josh Elser commented on CALCITE-642: Just pushed a big changeset to the pull request. It was a long road around, but I think I'm happy with where we ended up: * Introduced an avatica-metrics API which is all that avatica (client) depends on. This includes a "noop" implementation which removed lots of null/optional checking. * Introduced a dropwizard-metrics v3 implementation of avatica-metrics. * ServiceLoader is used to find one (and only one) implementation. Otherwise the noop implementation is used. (the noop implementation doesn't have a META-INF/services entry for this) * Also included the dropwizard-metrics to hadoop metrics2 as a standalone module in calcite (my glance upstream at dropwizard showed that the next version will be 4.y.z and includes a package renaming -- I'm hoping we can act as the host for this code until we get it pushed upstream and it can flourish there). * Lots of tests One thing I avoided was making a new avatica shaded jar with the metrics implementation included. This really boiled down to a new dependency in the downstream project (phoenix), so I was OK with this for now. More use by consumers other than myself will tell. [~julianhyde], if you'd like to look at the change before I merge, let me know. I believe this approach should be satisfactory to your already-stated concerns. I'm waiting to get a positive from travis (or at least what Travis would run itself). > Avatica server metrics > -- > > Key: CALCITE-642 > URL: https://issues.apache.org/jira/browse/CALCITE-642 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser > Labels: avatica > Fix For: next > > > Along the same lines as CALCITE-641, avatica server should track some basic > metrics. We can expose them through a "standard" API (such as Hadoop metrics, > or Dropwizard metrics), and include them on some interval in the service log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
