[jira] [Commented] (CALCITE-1192) Document protobuf and json REP types with examples
[ https://issues.apache.org/jira/browse/CALCITE-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245857#comment-15245857 ] Josh Elser commented on CALCITE-1192: - CALCITE-1205 has the fix to the field name in TypedValue to correct that. I just pushed https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=6ddd7821222f1a3e9480c205fdcfa8119b1277c3 which makes the json and protobuf docs consistent about how those date/type datatypes are serialized as numbers. Thanks for taking a look, Francis. > Document protobuf and json REP types with examples > -- > > Key: CALCITE-1192 > URL: https://issues.apache.org/jira/browse/CALCITE-1192 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Assignee: Josh Elser > Fix For: avatica-1.8.0 > > > It would be nice to have the documentation for the Rep types here > (https://calcite.apache.org/docs/avatica_protobuf_reference.html#rep) > documented with examples to show what the serialized representation looks > like. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1205) Inconsistency in protobuf TypedValue field names
Josh Elser created CALCITE-1205: --- Summary: Inconsistency in protobuf TypedValue field names Key: CALCITE-1205 URL: https://issues.apache.org/jira/browse/CALCITE-1205 Project: Calcite Issue Type: Bug Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Minor Fix For: avatica-1.8.0 [~francischuang] pointed out over in CALCITE-1192 that the "byte array" field in the protobuf TypedValue message has the name "bytes_values" instead of "bytes_value". Plural here does not make sense (as it is a single collection of bytes, not multiple collections of bytes). Changing the field name will not have an affect on binary compatibility, so I'm going to go ahead and make that change. The java API will change ever-so-slightly, but we haven't defined what our Java API is truly comprised of and to what degree we are providing stability, so we'll just ignore that for now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1315) Automatically retry request when a server fails to deliver an HTTP response
[
https://issues.apache.org/jira/browse/CALCITE-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1315.
-
Resolution: Fixed
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=799e1b083b57d2295681d3e58c4d88563f7ccc91
> Automatically retry request when a server fails to deliver an HTTP response
> ---
>
> Key: CALCITE-1315
> URL: https://issues.apache.org/jira/browse/CALCITE-1315
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> I've been running my load-balancer test using HAProxy between an Avatica
> client and multiple avatica servers. With the help of [~speleato], we've
> noticed that we're still seeing some intermittent failures in the client when
> we take down a backend server.
> The client reports a NoHttpResponseException:
> {noformat}
> java.lang.RuntimeException: org.apache.http.NoHttpResponseException:
> localhost: failed to respond
> at
> org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientImpl.send(AvaticaCommonsHttpClientImpl.java:149)
> at
> org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:44)
> at
> org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:69)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$14.call(RemoteMeta.java:307)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$14.call(RemoteMeta.java:305)
> at
> org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:715)
> at
> org.apache.calcite.avatica.remote.RemoteMeta.fetch(RemoteMeta.java:304)
> at
> org.apache.calcite.avatica.MetaImpl$FetchIterator.moveNext(MetaImpl.java:908)
> at
> org.apache.calcite.avatica.MetaImpl$FetchIterator.next(MetaImpl.java:893)
> at
> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at
> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:218)
> at sqlline.BufferedRows.(BufferedRows.java:37)
> at sqlline.SqlLine.print(SqlLine.java:1649)
> at sqlline.Commands.execute(Commands.java:833)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:807)
> at sqlline.SqlLine.runCommands(SqlLine.java:1710)
> 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:803)
> 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)
> at
> org.apache.phoenix.queryserver.client.SqllineWrapper.main(SqllineWrapper.java:83)
> Caused by: org.apache.http.NoHttpResponseException: localhost: failed to
> respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientImpl.execute(AvaticaCommonsHttpClientImpl.java:157)
> at
>
[jira] [Commented] (CALCITE-1315) Automatically retry request when a server fails to deliver an HTTP response
[
https://issues.apache.org/jira/browse/CALCITE-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15378490#comment-15378490
]
Josh Elser commented on CALCITE-1315:
-
bq. I don't know the semantics of NoHttpResponseException. Is it possible for a
server to repeatedly return NoHttpResponseException? If so, should you limit
the number of retries, to avoid a loop?
Not sure if it's not re-used elsewhere (don't have enough experience with HC to
be confident that they wouldnt' do something screwy), but, under normal
circumstances, we shouldn't ever get into a situation where we can connect to a
server, send a request, and get no bytes back from that server (if it's
dead/dying, it should stop accepting the connection before we send our request).
That said, I'm not a huge fan of our existing logic inside of the
AvaticaHttpClient impls for the reason you point out. We have very little
insight into retries happening too (often because logging is minimized because
we're in the context of sqlline or similar). Consolidating retry logic and
making sure we have appropriate options to control those client-side retries as
well as options exposed via the JDBC url would be a very good thing, but I need
to put some more thought into the knobs that are actually necessary (to avoid
death-by-configuratin).
Let me file another issue to look at this for 1.9.0.
> Automatically retry request when a server fails to deliver an HTTP response
> ---
>
> Key: CALCITE-1315
> URL: https://issues.apache.org/jira/browse/CALCITE-1315
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> I've been running my load-balancer test using HAProxy between an Avatica
> client and multiple avatica servers. With the help of [~speleato], we've
> noticed that we're still seeing some intermittent failures in the client when
> we take down a backend server.
> The client reports a NoHttpResponseException:
> {noformat}
> java.lang.RuntimeException: org.apache.http.NoHttpResponseException:
> localhost: failed to respond
> at
> org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientImpl.send(AvaticaCommonsHttpClientImpl.java:149)
> at
> org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:44)
> at
> org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:69)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$14.call(RemoteMeta.java:307)
> at
> org.apache.calcite.avatica.remote.RemoteMeta$14.call(RemoteMeta.java:305)
> at
> org.apache.calcite.avatica.AvaticaConnection.invokeWithRetries(AvaticaConnection.java:715)
> at
> org.apache.calcite.avatica.remote.RemoteMeta.fetch(RemoteMeta.java:304)
> at
> org.apache.calcite.avatica.MetaImpl$FetchIterator.moveNext(MetaImpl.java:908)
> at
> org.apache.calcite.avatica.MetaImpl$FetchIterator.next(MetaImpl.java:893)
> at
> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at
> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:218)
> at sqlline.BufferedRows.(BufferedRows.java:37)
> at sqlline.SqlLine.print(SqlLine.java:1649)
> at sqlline.Commands.execute(Commands.java:833)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:807)
> at sqlline.SqlLine.runCommands(SqlLine.java:1710)
> 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:803)
> 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)
> at
> org.apache.phoenix.queryserver.client.SqllineWrapper.main(SqllineWrapper.java:83)
> Caused by: org.apache.http.NoHttpResponseException: localhost: failed to
> respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at
>
[jira] [Commented] (CALCITE-1320) Whenever I try to prepare then execute a query it fails, but prepareAndExecute works fine, avatica protobufs
[
https://issues.apache.org/jira/browse/CALCITE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388807#comment-15388807
]
Josh Elser commented on CALCITE-1320:
-
What version of Avatica were you using?
> Whenever I try to prepare then execute a query it fails, but
> prepareAndExecute works fine, avatica protobufs
>
>
> Key: CALCITE-1320
> URL: https://issues.apache.org/jira/browse/CALCITE-1320
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Environment: python
> I uploaded the client to my github
> https://github.com/CheyenneForbes/python-phoenixdb-protobufs
>Reporter: Cheyenne
>Assignee: Julian Hyde
> Labels: avatica
>
> Whenever I try to prepare then execute a query it fails, but
> prepareAndExecute works fine, avatica protobufs. The error I get is:
> {noformat}
> java.lang.IllegalArgumentException: cannot convert false (class
> java.lang.Boolean) to PRIMITIVE_BOOLEAN
> at
> org.apache.calcite.avatica.remote.TypedValue.serialToLocal(TypedValue.java:242)
> at
> org.apache.calcite.avatica.remote.TypedValue.serialToJdbc(TypedValue.java:309)
> at org.apache.calcite.avatica.remote.TypedValue.toJdbc(TypedValue.java:290)
> at org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:793)
> at org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:234)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1167)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1145)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:38)
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.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:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> 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)
> ]IllegalArgumentException: cannot convert false (class java.lang.Boolean) to
> PRIMITIVE_BOOLEAN {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1335) ArrayImpl to return JDBC objects for method getArray()
[ https://issues.apache.org/jira/browse/CALCITE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406143#comment-15406143 ] Josh Elser commented on CALCITE-1335: - In case you weren't aware, the support for Arrays in the Avatica wire protocol are also lacking. It's on my list to get around to CALCITE-1050 > ArrayImpl to return JDBC objects for method getArray() > -- > > Key: CALCITE-1335 > URL: https://issues.apache.org/jira/browse/CALCITE-1335 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.8.0 >Reporter: Maryann Xue > > Avatica uses Integer or Long representations for Date/Time/Timestamp objects, > and similarly for Date/Time/Timestamp array objects. However, when calling > getArray() method, the array implementation (class ArrayImpl) should decode > from its internal representation and convert it into JDBC types before > returning the objects to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1350) Avoid closeConnection when openConnection doesn't finish/succeed
Josh Elser created CALCITE-1350: --- Summary: Avoid closeConnection when openConnection doesn't finish/succeed Key: CALCITE-1350 URL: https://issues.apache.org/jira/browse/CALCITE-1350 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.9.0 I've noticed during testing of Avatica, often times when SPNEGO authentication is misconfigured, the client will get stuck in openConnection(). If we consider sqlline and the user control-C's it, sqlline will try to close the driver as well which would do a closeConnection() (which would also obviously fail). I believe we should be able to short-circuit the the closeConnection() when we know that the openConnection() didn't succeed properly. Another scenario is when the Avatica server is down. openConnection will fail, but we'll still attempt the closeConnection on exit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1350) Avoid closeConnection when openConnection doesn't finish/succeed
[ https://issues.apache.org/jira/browse/CALCITE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418351#comment-15418351 ] Josh Elser commented on CALCITE-1350: - Right you are as always, Julian. Lost messages between client and server are definitely a concern. There's a bit of digging implicit in this one -- I just wanted to make sure I did not forget about the idea when I have a chance to look into this. Worst case, we might saturate the server with open JDBC connections if we incorrectly thought the server never opened them. However, this is tempered already by the eviction of connections that are not used within 10mins (by default). This would have to be a rare case to be acceptable. Consideration/thought definitely required. > Avoid closeConnection when openConnection doesn't finish/succeed > > > Key: CALCITE-1350 > URL: https://issues.apache.org/jira/browse/CALCITE-1350 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > I've noticed during testing of Avatica, often times when SPNEGO > authentication is misconfigured, the client will get stuck in > openConnection(). > If we consider sqlline and the user control-C's it, sqlline will try to close > the driver as well which would do a closeConnection() (which would also > obviously fail). > I believe we should be able to short-circuit the the closeConnection() when > we know that the openConnection() didn't succeed properly. > Another scenario is when the Avatica server is down. openConnection will > fail, but we'll still attempt the closeConnection on exit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1323) Wrong prefix number in DelegatingScope.fullyQualify()
[ https://issues.apache.org/jira/browse/CALCITE-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1323. - Resolution: Duplicate Assignee: (was: Julian Hyde) Duplicate of CALCITE-1322 > Wrong prefix number in DelegatingScope.fullyQualify() > - > > Key: CALCITE-1323 > URL: https://issues.apache.org/jira/browse/CALCITE-1323 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.7.0 >Reporter: Vitalii Diravka >Priority: Minor > > The issue in the _DelegatingScope.fullyQualify()_. > The prefix number must be _identifier.names.size()-1_ instead of _1_ in > _identifier.isStar()_ condition statement. > The case for reproducing - the asterisk with full schema identifier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1311) Add high-level record of interactions with the avatica server
[ https://issues.apache.org/jira/browse/CALCITE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15381413#comment-15381413 ] Josh Elser commented on CALCITE-1311: - bq. I'd like to see an argument made that this is the best/only place in the architecture where this can be done. Making such an argument is definitely difficult to do because actual architectures can vary so wildly from group to group. Some hypothetical's to outline this: * Avatica is being used just as a front-end to a traditional database to limit physical access to the database. In this case, the traditional database would likely do a much better job at recording an audit log. Avatica providing this functionality would be unnecessary and the databases' functionality should be used instead. * Consider the case where Calcite's JDBC driver is used inside of Avatica to provide access to ElasticSearch, Druid, and a traditional database. Each of these three backend systems *may* have their own audit logging functionality built in (I actually don't know if ES and Druid have this -- let's assume they do). The administrator could see the query that was run on each of these systems by Calcite, but the original query that a user submitted to Avatica would be lost. For example, if some query was extracting data from multiple systems, it would be desirable to know what the user entered in addition to the final query which was run on the backend. Taking the 2nd example even further, what if Calcite applied some rules to the user query which resulted in an incorrect query on the backend. It would be desirable to know what the user-entered query was to be able to investigate/reproduce the situation -- knowing only the final query that was run on the "real database" system would insufficient. * Building in this functionality to Avatica could also be used as a single place to implement sending of these audit logs to external systems. It is likely that not all databases have the ability to report audit logs to external systems. Avatica could serve as a central place for implementations to these various systems instead of having to implement them for any/every database. In short, I'd agree with you that I don't think this feature would be applicable or beneficial for all use cases, but I feel like there are scenarios where it would provide some worth. Similar to the recent authentication work, we should not only inform users about the feature, but when it's appropriate to use the feature too. WDYT? > Add high-level record of interactions with the avatica server > - > > Key: CALCITE-1311 > URL: https://issues.apache.org/jira/browse/CALCITE-1311 > Project: Calcite > Issue Type: New Feature > Components: avatica >Reporter: Josh Elser > > It would be nice to have the ability to configure the Avatica server to > create what is equivalent to an "audit log". > This functionality would provide administrators the ability to inspect what > queries were run and the user (client address and optionally the Kerberos > identity). > It would be nice to implement this as a framework and provide an initial > "sink" binding which just writes to a file. This would let us push these logs > to other systems automatically which would be nice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1316) Better control over retried operations in Avatica client
Josh Elser created CALCITE-1316: --- Summary: Better control over retried operations in Avatica client Key: CALCITE-1316 URL: https://issues.apache.org/jira/browse/CALCITE-1316 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.9.0 We have at least two places in the Avatica client now where we will try to re-issue "RPCs" in the attempt to work seamlessly with load-balanced servers. Between these two places, we have finite retries, infinite retries and no standardized back-off strategies. We should try to centralize this into one place and make sure that users can override the logic, heaven forbid they come up with some situation where it's necessary. Need to investigate the retry-loops we have in the Avatica client now, categorize the loops and come up with a minimal set of knobs to configure the retries, expose those knobs in the JDBC URL string options, and update the documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1308) Primary Keys for Phoenix table not recognized in sqlline.
[ https://issues.apache.org/jira/browse/CALCITE-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367750#comment-15367750 ] Josh Elser commented on CALCITE-1308: - bq. Phoenix implements DatabaseMetaData.getPrimaryKeys(). Yup, I have no reason to think that it's a Phoenix issue at this point. bq. It sounds as if sqlline is doing the right thing given the information it is getting, and Avatica is doing the right thing Not entirely sure if this is true yet. I need to spend some more quality time with a debugger. I just saw enough that the getPrimaryKeys call that sqlline was making _looked_ correct but received no data. Need to dig some more. > Primary Keys for Phoenix table not recognized in sqlline. > - > > Key: CALCITE-1308 > URL: https://issues.apache.org/jira/browse/CALCITE-1308 > Project: Calcite > Issue Type: Bug >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: avatica-1.9.0 > > > Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are > (part of the) primary key. Running a debugger over it quickly, showed that no > keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1308) Implement DatabaseMetaData operations in RemoteMeta
[ https://issues.apache.org/jira/browse/CALCITE-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1308: Summary: Implement DatabaseMetaData operations in RemoteMeta (was: Primary Keys for Phoenix table not recognized in sqlline.) > Implement DatabaseMetaData operations in RemoteMeta > --- > > Key: CALCITE-1308 > URL: https://issues.apache.org/jira/browse/CALCITE-1308 > Project: Calcite > Issue Type: Bug >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: avatica-1.9.0 > > > Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are > (part of the) primary key. Running a debugger over it quickly, showed that no > keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1308) Implement remaining DatabaseMetaData operations in RemoteMeta
[ https://issues.apache.org/jira/browse/CALCITE-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1308: Summary: Implement remaining DatabaseMetaData operations in RemoteMeta (was: Implement DatabaseMetaData operations in RemoteMeta) > Implement remaining DatabaseMetaData operations in RemoteMeta > - > > Key: CALCITE-1308 > URL: https://issues.apache.org/jira/browse/CALCITE-1308 > Project: Calcite > Issue Type: Bug >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: avatica-1.9.0 > > > Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are > (part of the) primary key. Running a debugger over it quickly, showed that no > keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1308) Implement remaining DatabaseMetaData operations in RemoteMeta
[
https://issues.apache.org/jira/browse/CALCITE-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368396#comment-15368396
]
Josh Elser commented on CALCITE-1308:
-
{code}
getAttributes(ConnectionHandle, String, Pat, Pat, Pat)
getBestRowIdentifier(ConnectionHandle, String, String, String, int, boolean)
getClientInfoProperties(ConnectionHandle)
getColumnPrivileges(ConnectionHandle, String, String, String, Pat)
getCrossReference(ConnectionHandle, String, String, String, String, String,
String)
getExportedKeys(ConnectionHandle, String, String, String)
getFunctionColumns(ConnectionHandle, String, Pat, Pat, Pat)
getFunctions(ConnectionHandle, String, Pat, Pat)
getImportedKeys(ConnectionHandle, String, String, String)
getIndexInfo(ConnectionHandle, String, String, String, boolean, boolean)
getPrimaryKeys(ConnectionHandle, String, String, String)
getProcedureColumns(ConnectionHandle, String, Pat, Pat, Pat)
getProcedures(ConnectionHandle, String, Pat, Pat)
getPseudoColumns(ConnectionHandle, String, Pat, Pat, Pat)
getSuperTables(ConnectionHandle, String, Pat, Pat)
getSuperTypes(ConnectionHandle, String, Pat, Pat)
getTablePrivileges(ConnectionHandle, String, Pat, Pat)
getUDTs(ConnectionHandle, String, Pat, Pat, int[])
getVersionColumns(ConnectionHandle, String, String, String)
{code}
The methods on Meta which need reviewing (and potentially, implementations)
> Implement remaining DatabaseMetaData operations in RemoteMeta
> -
>
> Key: CALCITE-1308
> URL: https://issues.apache.org/jira/browse/CALCITE-1308
> Project: Calcite
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are
> (part of the) primary key. Running a debugger over it quickly, showed that no
> keys were returned over the DatabaseMetaData.getPrimaryKeys call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1308) Implement remaining DatabaseMetaData operations in RemoteMeta
[ https://issues.apache.org/jira/browse/CALCITE-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1308: Priority: Critical (was: Minor) > Implement remaining DatabaseMetaData operations in RemoteMeta > - > > Key: CALCITE-1308 > URL: https://issues.apache.org/jira/browse/CALCITE-1308 > Project: Calcite > Issue Type: Bug >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.9.0 > > > Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are > (part of the) primary key. Running a debugger over it quickly, showed that no > keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1308) Primary Keys for Phoenix table not recognized in sqlline.
Josh Elser created CALCITE-1308: --- Summary: Primary Keys for Phoenix table not recognized in sqlline. Key: CALCITE-1308 URL: https://issues.apache.org/jira/browse/CALCITE-1308 Project: Calcite Issue Type: Bug Reporter: Josh Elser Assignee: Josh Elser Priority: Minor Fix For: avatica-1.9.0 Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are (part of the) primary key. Running a debugger over it quickly, showed that no keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1311) Add high-level record of interactions with the avatica server
[ https://issues.apache.org/jira/browse/CALCITE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371159#comment-15371159 ] Josh Elser commented on CALCITE-1311: - bq. It would very nice to have this, but is it scope creep? If the backend server already has auditing it wouldn't want Avatica doing it at another level. Good point. It might very well be duplicative of something that backend system is already doing. Definitely should be an optional thing (if built) bq. Are we talking about data auditing here (e.g. if there is a batch insert of 100 rows, write those 100 rows out somewhere)? bq. How does this capability compare with metrics? Events such as "connection created", "statement canceled" are similar to those that would be gathered by metrics. So, would auditing and metrics write to the same place, and would they use the same mechanism? For the read side, I think it's pretty straightforward to just log the SQL statement. For writes and metadata operations, I'm not sure what exactly these would look like (would we log the Avatica method call? The insert/update template assuming that it's a prepared statement?). How it fits in with metrics is also a concern to avoid two features potentially colliding. My initial thoughts would be that metrics are raw timing data for the Avatica calls whereas this would be a "user level" record of what happened. We would definitely need to make sure that the delineation between the two are clear. Definitely still hashing out what this would look like; more feedback/opinions are welcomed :) > Add high-level record of interactions with the avatica server > - > > Key: CALCITE-1311 > URL: https://issues.apache.org/jira/browse/CALCITE-1311 > Project: Calcite > Issue Type: New Feature > Components: avatica >Reporter: Josh Elser > > It would be nice to have the ability to configure the Avatica server to > create what is equivalent to an "audit log". > This functionality would provide administrators the ability to inspect what > queries were run and the user (client address and optionally the Kerberos > identity). > It would be nice to implement this as a framework and provide an initial > "sink" binding which just writes to a file. This would let us push these logs > to other systems automatically which would be nice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1311) Add high-level record of interactions with the avatica server
Josh Elser created CALCITE-1311: --- Summary: Add high-level record of interactions with the avatica server Key: CALCITE-1311 URL: https://issues.apache.org/jira/browse/CALCITE-1311 Project: Calcite Issue Type: New Feature Components: avatica Reporter: Josh Elser It would be nice to have the ability to configure the Avatica server to create what is equivalent to an "audit log". This functionality would provide administrators the ability to inspect what queries were run and the user (client address and optionally the Kerberos identity). It would be nice to implement this as a framework and provide an initial "sink" binding which just writes to a file. This would let us push these logs to other systems automatically which would be nice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1602) Remove uses of deprecated APIs
[
https://issues.apache.org/jira/browse/CALCITE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15838080#comment-15838080
]
Josh Elser commented on CALCITE-1602:
-
bq. If people introduce warnings the build won't fail, but my
calcite-regress.sh script will, and you'll soon get an email from me
I was wondering how you were planning to do this :). If you'd like, I can help
you set up a new job on the ASF jenkins to run this script and email offenders
so that we're not reliant on your personal builds or time sending an email.
bq. Enforcement will be asynchronous
It'd be great if we could catch it synchronously, but I don't know of a maven
plugin that would do this check. Maybe it's an option on the compiler-plugin?
Would have to do some searching, but I didn't want to derail your current plan.
> Remove uses of deprecated APIs
> --
>
> Key: CALCITE-1602
> URL: https://issues.apache.org/jira/browse/CALCITE-1602
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Calcite should not use deprecated methods and classes, especially in
> third-party libraries. I propose that we adopt a zero-tolerance policy,
> fixing deprecated calls as soon as they occur. As long as the third-party
> libraries use semantic versioning, this should give us prior warning before
> things disappear.
> You can find the calls to deprecated APIs by adding
> {{-Xlint:deprecation}} then running
> {{mvn clean package -DskipTests | grep 'has been deprecated' | grep -v 'in
> org.apache.calcite'}}. Currently there are 51 when you run in JDK9 and Guava
> 20.0. Here are the first few:
> {noformat}
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/main/java/org/apache/calcite/linq4j/tree/Types.java:[254,38]
> getPackage(java.lang.String) in java.lang.Package has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[736,25]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[737,26]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[738,25]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/rex/RexBuilder.java:[539,47]
> ROUND_HALF_DOWN in java.math.BigDecimal has been deprecated
> {noformat}
> We should fix these (and other deprecated APIs when we run on other JDK
> versions and other Guava versions), then add a nightly check that none are
> added back.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1602) Remove uses of deprecated APIs
[
https://issues.apache.org/jira/browse/CALCITE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15838155#comment-15838155
]
Josh Elser commented on CALCITE-1602:
-
bq. My inclination is not to try to automate anything in ASF infrastructure.
Managing a flaky server in an environment one doesn't control is a huge time
sink.
I would have agreed with you half a year ago, but I've actually been seeing
much more stable builds coming out of builds.a.o lately. Anyways, offer stands,
but it's your time/interest in the problem -- I don't want to be telling you
how to spend it :)
> Remove uses of deprecated APIs
> --
>
> Key: CALCITE-1602
> URL: https://issues.apache.org/jira/browse/CALCITE-1602
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Calcite should not use deprecated methods and classes, especially in
> third-party libraries. I propose that we adopt a zero-tolerance policy,
> fixing deprecated calls as soon as they occur. As long as the third-party
> libraries use semantic versioning, this should give us prior warning before
> things disappear.
> You can find the calls to deprecated APIs by adding
> {{-Xlint:deprecation}} then running
> {{mvn clean package -DskipTests | grep 'has been deprecated' | grep -v 'in
> org.apache.calcite'}}. Currently there are 51 when you run in JDK9 and Guava
> 20.0. Here are the first few:
> {noformat}
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/main/java/org/apache/calcite/linq4j/tree/Types.java:[254,38]
> getPackage(java.lang.String) in java.lang.Package has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[736,25]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[737,26]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[738,25]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/rex/RexBuilder.java:[539,47]
> ROUND_HALF_DOWN in java.math.BigDecimal has been deprecated
> {noformat}
> We should fix these (and other deprecated APIs when we run on other JDK
> versions and other Guava versions), then add a nightly check that none are
> added back.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1602) Remove uses of deprecated external APIs
[
https://issues.apache.org/jira/browse/CALCITE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15836918#comment-15836918
]
Josh Elser commented on CALCITE-1602:
-
bq. I propose that we adopt a zero-tolerance policy, fixing deprecated calls as
soon as they occur.
+1
bq. We should fix these (and other deprecated APIs when we run on other JDK
versions and other Guava versions), then add a nightly check that none are
added back.
+1
> Remove uses of deprecated external APIs
> ---
>
> Key: CALCITE-1602
> URL: https://issues.apache.org/jira/browse/CALCITE-1602
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Calcite should not use deprecated methods and classes, especially in
> third-party libraries. I propose that we adopt a zero-tolerance policy,
> fixing deprecated calls as soon as they occur. As long as the third-party
> libraries use semantic versioning, this should give us prior warning before
> things disappear.
> You can find the calls to deprecated APIs by adding
> {{-Xlint:deprecation}} then running
> {{mvn clean package -DskipTests | grep 'has been deprecated' | grep -v 'in
> org.apache.calcite'}}. Currently there are 51 when you run in JDK9 and Guava
> 20.0. Here are the first few:
> {noformat}
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/main/java/org/apache/calcite/linq4j/tree/Types.java:[254,38]
> getPackage(java.lang.String) in java.lang.Package has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[736,25]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[737,26]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/linq4j/src/test/java/org/apache/calcite/linq4j/test/Linq4jTest.java:[738,25]
> Integer(int) in java.lang.Integer has been deprecated
> [WARNING]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/rex/RexBuilder.java:[539,47]
> ROUND_HALF_DOWN in java.math.BigDecimal has been deprecated
> {noformat}
> We should fix these (and other deprecated APIs when we run on other JDK
> versions and other Guava versions), then add a nightly check that none are
> added back.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1654) Serialized messages are generated even though they are not logged
[ https://issues.apache.org/jira/browse/CALCITE-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15879235#comment-15879235 ] Josh Elser commented on CALCITE-1654: - Put up a pull-request with the trivial change.. https://github.com/apache/calcite/pull/380 > Serialized messages are generated even though they are not logged > - > > Key: CALCITE-1654 > URL: https://issues.apache.org/jira/browse/CALCITE-1654 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Sergey Soldatov >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.10.0 > > > [~sergey.soldatov] made a good find through some careful log reading. > In ProtobufTranslationImpl, some TRACE logging that I had added in > CALCITE-1159 is causing a bunch of garbage to be created on the heap. > The trace logging messages should be wrapped in a conditionals to avoid the > generation of the message itself. I was a little too overzealous thinking > that the slf4j api was saving me. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CALCITE-1654) Serialized messages are generated even though they are not logged
[ https://issues.apache.org/jira/browse/CALCITE-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1654. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=1b11385687171946d961fc4c836ee348f682b00a > Serialized messages are generated even though they are not logged > - > > Key: CALCITE-1654 > URL: https://issues.apache.org/jira/browse/CALCITE-1654 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Sergey Soldatov >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.10.0 > > > [~sergey.soldatov] made a good find through some careful log reading. > In ProtobufTranslationImpl, some TRACE logging that I had added in > CALCITE-1159 is causing a bunch of garbage to be created on the heap. > The trace logging messages should be wrapped in a conditionals to avoid the > generation of the message itself. I was a little too overzealous thinking > that the slf4j api was saving me. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CALCITE-1654) Serialized messages are generated even though they are not logged
Josh Elser created CALCITE-1654: --- Summary: Serialized messages are generated even though they are not logged Key: CALCITE-1654 URL: https://issues.apache.org/jira/browse/CALCITE-1654 Project: Calcite Issue Type: Bug Components: avatica Reporter: Sergey Soldatov Assignee: Josh Elser Priority: Critical Fix For: avatica-1.10.0 [~sergey.soldatov] made a good find through some careful log reading. In ProtobufTranslationImpl, some TRACE logging that I had added in CALCITE-1159 is causing a bunch of garbage to be created on the heap. The trace logging messages should be wrapped in a conditionals to avoid the generation of the message itself. I was a little too overzealous thinking that the slf4j api was saving me. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[ https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-1539: --- Assignee: Shi Wang (was: Josh Elser) > Enable proxy access to Avatica server for third party on behalf of end users > > > Key: CALCITE-1539 > URL: https://issues.apache.org/jira/browse/CALCITE-1539 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Jerry He >Assignee: Shi Wang > Attachments: > 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch > > > We want to enable proxy access to Avatica server from an end user, but the > end user comes in via a third party impersonation. For example, Knox and Hue. > The Knox server user conveys the end user to Avatica. > Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server > HIVE-5155 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CALCITE-1320) Whenever I try to prepare then execute a query it fails, but prepareAndExecute works fine, avatica protobufs
[
https://issues.apache.org/jira/browse/CALCITE-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1320.
-
Resolution: Incomplete
Please re-open if you have more context/information. There is upstream support
for protobufs in python-phoenixdb. Please use that.
> Whenever I try to prepare then execute a query it fails, but
> prepareAndExecute works fine, avatica protobufs
>
>
> Key: CALCITE-1320
> URL: https://issues.apache.org/jira/browse/CALCITE-1320
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Environment: python
> I uploaded the client to my github
> https://github.com/CheyenneForbes/python-phoenixdb-protobufs
>Reporter: Cheyenne
>Assignee: Julian Hyde
> Labels: avatica
>
> Whenever I try to prepare then execute a query it fails, but
> prepareAndExecute works fine, avatica protobufs. The error I get is:
> {noformat}
> java.lang.IllegalArgumentException: cannot convert false (class
> java.lang.Boolean) to PRIMITIVE_BOOLEAN
> at
> org.apache.calcite.avatica.remote.TypedValue.serialToLocal(TypedValue.java:242)
> at
> org.apache.calcite.avatica.remote.TypedValue.serialToJdbc(TypedValue.java:309)
> at org.apache.calcite.avatica.remote.TypedValue.toJdbc(TypedValue.java:290)
> at org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:793)
> at org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:234)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1167)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1145)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:38)
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.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:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> 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)
> ]IllegalArgumentException: cannot convert false (class java.lang.Boolean) to
> PRIMITIVE_BOOLEAN {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[ https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863926#comment-15863926 ] Josh Elser commented on CALCITE-1539: - [~Wancy], are you still interested in fixing up your patch? > Enable proxy access to Avatica server for third party on behalf of end users > > > Key: CALCITE-1539 > URL: https://issues.apache.org/jira/browse/CALCITE-1539 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Jerry He >Assignee: Josh Elser > Attachments: > 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch > > > We want to enable proxy access to Avatica server from an end user, but the > end user comes in via a third party impersonation. For example, Knox and Hue. > The Knox server user conveys the end user to Avatica. > Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server > HIVE-5155 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1625) add basic JDBC statistics
[
https://issues.apache.org/jira/browse/CALCITE-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859932#comment-15859932
]
Josh Elser commented on CALCITE-1625:
-
Beware that we're probably going to also run into CALCITE-1308 as a blocker
before we could do this one.
> add basic JDBC statistics
> -
>
> Key: CALCITE-1625
> URL: https://issues.apache.org/jira/browse/CALCITE-1625
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jess Balint
>Assignee: Julian Hyde
>Priority: Minor
>
> basic JDBC statistics can be retrieved via
> {{DatabaseMetaData.getIndexInfo()}}. This can be used in the underlying
> {{JdbcTable}} to provide stats/key info during planning.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1625) add basic JDBC statistics
[
https://issues.apache.org/jira/browse/CALCITE-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860003#comment-15860003
]
Josh Elser commented on CALCITE-1625:
-
bq. I'm primarily interested in adding statistics under JdbcTable. Afaik, this
is not related to Avatica
Ok, sorry if I'm derailing this :). I assumed it was going through the Calcite
JDBC driver which would inherit the problem. If it's using any JDBC driver,
you're right, it's unrelated.
> add basic JDBC statistics
> -
>
> Key: CALCITE-1625
> URL: https://issues.apache.org/jira/browse/CALCITE-1625
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jess Balint
>Assignee: Julian Hyde
>Priority: Minor
>
> basic JDBC statistics can be retrieved via
> {{DatabaseMetaData.getIndexInfo()}}. This can be used in the underlying
> {{JdbcTable}} to provide stats/key info during planning.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1576) Use protobuf-maven-plugin
Josh Elser created CALCITE-1576: --- Summary: Use protobuf-maven-plugin Key: CALCITE-1576 URL: https://issues.apache.org/jira/browse/CALCITE-1576 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.10.0 Use https://github.com/xolstice/protobuf-maven-plugin Can remove the need for the script presently in tree. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830792#comment-15830792
]
Josh Elser commented on CALCITE-1539:
-
bq. Which layer provides the implementation, Avatica or the implementation
layer (PQS)?
Sorry I wasn't more clear. I am purely talking in terms of Avatica. We are
creating multiple ways for an Avatica implementation (PQS) to extract what the
"remote user" of a request is.
Phoenix would still be providing it's own implementation for
{{DoAsRemoteUserCallback}}.
> Enable proxy access to Avatica server for third party on behalf of end users
>
>
> Key: CALCITE-1539
> URL: https://issues.apache.org/jira/browse/CALCITE-1539
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jerry He
>Assignee: Josh Elser
> Attachments:
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the
> end user comes in via a third party impersonation. For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server
> HIVE-5155
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830599#comment-15830599
]
Josh Elser commented on CALCITE-1539:
-
bq. Sorry I made a mistake in using request.getQueryString() which makes it
confusing. I meant to get the doAs parameter in the query, it should be
something like request.getParameter("doAs").
Gotcha. That makes more sense :)
bq. say we use user guest to authenticate on Knox(Knox demo ldap), and
according to getQueryString() method in
IdentityAsserterHttpServletRequestWrapper.java in Knox, it will put doAs=guest
in the request params
As I'm re-looking at {{AvaticaServerConfiguration#doAsRemoteUser(..)}}, I'm
realizing that the javadoc should be much more clear that the implementation
*must* verify that the caller (Knox, in your example) is allowed to impersonate
the requested user ("guest"). Need to make this very clear otherwise it's a
security hole :)
bq. Knox will redirect request to PQS. In this case, the remote user is Knox
and doAsUser is guest. (correct me if I am wrong)
bq. And to keep public T doAsRemoteUser(String remoteUserName, String
remoteAddress, final Callable action) throws Exception { this method, should
we write another method in Calcite interface to cover the case of doAsUser?
This is what I was trying to point out. {{remoteUserName}} should be {{guest}}
(admittedly, the naming/javadoc aren't as clear as they could be). There is no
need to have a new parameter to this method. Your change should provide the
ability to change how Avatica extracts the {{remoteUserName}} when it invokes
the {{doAsRemtoeUser}} method.
https://github.com/apache/calcite/blob/0938c7b6d767e3242874d87a30d9112512d9243a/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaProtobufHandler.java#L117-L122
https://github.com/apache/calcite/blob/0938c7b6d767e3242874d87a30d9112512d9243a/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaJsonHandler.java#L122-L127
I would consolidate these two classes to allow for the ability to pass either
{{request.getRemoteUser()}} or a certain parameter from the HTTP request's
query string (as you described in your above example). You would add this
configuration to AvaticaServerConfiguration with a new enumeration to control
this. Something like..
{code}
interface RemoteUserExtractor extends Callable {
String extractRemoteUser(HttpServletRequest request);
}
/**
* Extract the user this request should execute as.
*/
RemoteUserExtractor getRemoteUserExtractor();
{code}
Then, we can provide two implementations:
{code}
public class HttpRequestRemoteUserExtractor implements RemoteUserExtractor {
public String extractRemoteUser(HttpServletRequest request) {
return request.getRemoteUser();
}
}
public class HttpQueryStringParameterRemoteUserExtractor implements
RemoteUserExtractor {
public String extractRemtoeUser(HttpServletRequest request) {
return request.getParameter("doAs");
}
}
{code}
Does this make sense?
> Enable proxy access to Avatica server for third party on behalf of end users
>
>
> Key: CALCITE-1539
> URL: https://issues.apache.org/jira/browse/CALCITE-1539
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jerry He
>Assignee: Josh Elser
> Attachments:
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the
> end user comes in via a third party impersonation. For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server
> HIVE-5155
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1354) Release Avatica 1.9.0
Josh Elser created CALCITE-1354: --- Summary: Release Avatica 1.9.0 Key: CALCITE-1354 URL: https://issues.apache.org/jira/browse/CALCITE-1354 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Fix For: avatica-1.9.0 General issue to track the release (so I can better track downstream projects waiting on fixes from Avatica to be released). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1352) Clarify documentation for avatica's max_rows_total
[
https://issues.apache.org/jira/browse/CALCITE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431000#comment-15431000
]
Josh Elser commented on CALCITE-1352:
-
Thanks for opening this issue, [~francischuang]. Also, thanks for the context
[~julianhyde].
> Clarify documentation for avatica's max_rows_total
> --
>
> Key: CALCITE-1352
> URL: https://issues.apache.org/jira/browse/CALCITE-1352
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
>
> The {{max_rows_total}} parameter in the protocol buffer definitions should be
> updated to include more information on values that result in unlimited rows
> being returned.
> When testing against calcite 1.8.0, I observed the following:
> {code}
> -1: Unlimited number of rows
> 0: 0 rows
> 1: 1 row
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15430996#comment-15430996
]
Josh Elser commented on CALCITE-1353:
-
Good catch, [~francischuang]. Looks right to me. I should have changed this
from an int64 to a uint32 in CALCITE-1243. Will need to make a
backwards-compatible change since this was released in avatica-1.8.0
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>Priority: Minor
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1353:
Affects Version/s: avatica-1.8.0
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1353:
Fix Version/s: avatica-1.9.0
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1355) Upgrade to protobuf-java 3.0.0 (stable)
Josh Elser created CALCITE-1355: --- Summary: Upgrade to protobuf-java 3.0.0 (stable) Key: CALCITE-1355 URL: https://issues.apache.org/jira/browse/CALCITE-1355 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Blocker Fix For: avatica-1.9.0 Just noticed that protobuf-3.0.0 was released recently. https://github.com/google/protobuf/releases/tag/v3.0.0 We should bump up to that, making sure there aren't any advertised issues between the beta version we were using and 3.0.0 (final). Marked as blocker against the next Avatica release as having an official non-beta protobuf version will help downstream users write more clients against Avatica. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1369) Display a list of Avatica clients on the website
[ https://issues.apache.org/jira/browse/CALCITE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467949#comment-15467949 ] Josh Elser commented on CALCITE-1369: - +1 I like having all of the Calcite/Avatica docs centralized in the source tree. I like to think (hope, maybe?) that in this "Github era", sending a pull request is nearly as easy as editing a wiki. > Display a list of Avatica clients on the website > > > Key: CALCITE-1369 > URL: https://issues.apache.org/jira/browse/CALCITE-1369 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Priority: Minor > > I think it would be really neat to have a well organized list of Avatica > clients on the website. This would make clients much more discoverable and > make Avatica and Calcite much more easier for people to get started with. For > example, Kafka has a wiki page with their clients here: > https://cwiki.apache.org/confluence/display/KAFKA/Clients > 1. Most of the clients currently available (the .NET and python ones) are > currently targeted towards Apache Phoenix. Should we include these clients? > If not, is there a process for reaching out to their maintainers to see if > they are interested in generalising them to target Avatica? > 2. Is there any process for including a client on such a page? Should anyone > be able to add the client, or do we need explicit permission from the > maintainers? > 3. To reduce friction, is it viable to have a wiki page, so that maintainers > can easily add their own clients? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467959#comment-15467959
]
Josh Elser commented on CALCITE-1353:
-
bq. would it make sense to change it to a int32 rather than a uint32?
Yup, exactly. I think the reason that this is a 32bit number instead of 64bit
is because of Java's limit on array length.
bq. That way, if we want all the rows in the first frame, we could set it to -1.
Agreed (with the caveat on maximum number of rows in a {{Frame}}).
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1352) Clarify documentation for avatica's max_rows_total
[
https://issues.apache.org/jira/browse/CALCITE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1352:
Fix Version/s: avatica-1.9.0
> Clarify documentation for avatica's max_rows_total
> --
>
> Key: CALCITE-1352
> URL: https://issues.apache.org/jira/browse/CALCITE-1352
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> The {{max_rows_total}} parameter in the protocol buffer definitions should be
> updated to include more information on values that result in unlimited rows
> being returned.
> When testing against calcite 1.8.0, I observed the following:
> {code}
> -1: Unlimited number of rows
> 0: 0 rows
> 1: 1 row
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1354) Release Avatica 1.9.0
[ https://issues.apache.org/jira/browse/CALCITE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467965#comment-15467965 ] Josh Elser commented on CALCITE-1354: - Sure. I tagged it with the avatica-1.9.0 FixVersion for now. I'll try to get around to it, but would be happy to review a doc improvement from you too ;) > Release Avatica 1.9.0 > - > > Key: CALCITE-1354 > URL: https://issues.apache.org/jira/browse/CALCITE-1354 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser > Fix For: avatica-1.9.0 > > > General issue to track the release (so I can better track downstream projects > waiting on fixes from Avatica to be released). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1110) remove or relocate shaded jackson in Avatica
[
https://issues.apache.org/jira/browse/CALCITE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469142#comment-15469142
]
Josh Elser commented on CALCITE-1110:
-
Hi [~minjikim].
I think the approach (if/when I get to it myself), would be to provide shaded
and non-shaded versions of the Avatica "client" artifact. CALCITE-1224 covers
this one.
As I see it, this solves two cases for us:
# When you just want to use Avatica and don't want to worry about dependencies,
you use the shaded artifact and won't have any conflict (because the
dependencies are included and relocated).
# When you want to integrate Avatica with specific versions of Guava, Jackson,
etc, you can use the non-shaded client and provide the dependencies on your
applicaiton's classpath. There is some amount of increased test burden to make
sure that Avatica actually works with the versions of the dependencies you want
to use as a user (we only do minor testing of a range of Guava versions
presently).
Does that make sense? It is by no means the only way forward, and anything
you'd like to contribute would be a great addition, I'm sure.
> remove or relocate shaded jackson in Avatica
>
>
> Key: CALCITE-1110
> URL: https://issues.apache.org/jira/browse/CALCITE-1110
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.6.0, 1.5.0
>Reporter: Kai Gülzau
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> The avatica jar includes a shaded version of jackson under the original
> package path.
> This shaded version interferes with other jackson versions in the classpath.
> Currently this prevents us from using jackson functionality which is only
> implemented in newer versions.
> https://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3C977C7450-18F4-48E2-A970-69B7E3E1BD2C%40apache.org%3E
> {quote}
> Is it reasonable to have a maven profile that uses jackson as “provided”[1]
> rather than shading? This would not be the default — the default would be
> continue to use a shaded version of jackson (relocated to
> org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed
> calcite/avatica in a container might appreciate a lighter weight option.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1364) Bring Docker image for avatica-standalone-server into Apache
[
https://issues.apache.org/jira/browse/CALCITE-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446731#comment-15446731
]
Josh Elser commented on CALCITE-1364:
-
Thanks for the feedback, Julian.
bq. So I think you should make sure that
https://github.com/joshelser/avatica-hsqldb-docker is a valid Apache-licensed
open source project, with explicit license, notices, headers, and instructions.
Ya caught me ;) I need to clean up this stuff as well as the repo that I
created to support the older Avatica versions before I introduced that
standalone-server module to Avatica.
bq. We can't rely on https://hub.docker.com/ being always available but someone
should be able to achieve the same effect by forking your project.
My line of thinking was that we would have the Dockerfile available in Apache
source. People could build the image themselves -- this is a similar analogy to
Java source and jar files. I think of Docker Hub in the same way as I think of
Maven central in that regard -- a convenient canonical location to pull the
pre-built image from. As such, I was also hoping that users would have the
ability to {{docker pull apache/avatica-hsqldb:1.8.0}} (or similar).
That said, I wasn't explicit in writing, but there is a latent question with
filing this: is this something we want to own in Apache?
I admin that I'm not super excited about figuring out how to do this in Apache.
I can move must faster no my own :). However, my next steps here are to
automate running the TCK against these docker images (use docker swarm or
something to launch them, and create a new image to invoke the TCK
automatically). As such, I have an interest in making this simple execution
"owned" by Apache since the intended audience are the Apache developers
(although, it does not invalidate the ability for devs to run the TCK -- just
makes it harder). I am still thinking through this all.
> Bring Docker image for avatica-standalone-server into Apache
>
>
> Key: CALCITE-1364
> URL: https://issues.apache.org/jira/browse/CALCITE-1364
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> I worked on making some Docker images for the standalone Avatica Server with
> HSQLDB.
> https://hub.docker.com/r/joshelser/avatica-hsqldb/
> These greatly simplify running the Avatica TCK and also provide a portable
> server that developers can use when testing custom Avatica clients.
> For >=1.9.0, we should an image into Avatica (upstream). There are a couple
> of open questions on my mind already:
> 1. What are the release-ability concerns (do we provide SNAPSHOT Dockerfiles
> but not built images as they may be interpreted as "releases")?
> 2. What ASF integrations exist (do we need to ask Infra for things?)
> 3. Are there any maven plugins we should consider for automation?
> (https://github.com/spotify/docker-maven-plugin)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1371) PreparedStatement does not process Date type correctly
[
https://issues.apache.org/jira/browse/CALCITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1371:
Fix Version/s: avatica-1.9.0
> PreparedStatement does not process Date type correctly
> ---
>
> Key: CALCITE-1371
> URL: https://issues.apache.org/jira/browse/CALCITE-1371
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.8.0
>Reporter: Billy(Yiming) Liu
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> I have problem when passing date parameter in PreparedStatement. Following is
> the sample code:
> TimeZone tzUtc = TimeZone.getTimeZone("UTC");
> Calendar cUtc = Calendar.getInstance(tzUtc);
> cUtc.set(2013, 10, 5, 0, 0, 0);
> java.sql.Date passSqlDate = new java.sql.Date(cUtc.getTimeInMillis());
> statement.setDate(1, passSqlDate, cUtc);
> I try to pass Date'2013/11/5' to the database, but from the debug info I
> found the
> database received '2013/10/4' (GMT -8 Timezone) always. It ignored the
> Calendar I passed in.
> There are some Calcite code a little strange, I have marked by color:
> Why setTimestamp and setTime have effective parameter 'calendar', but setDate
> ignore the
> parameter. Is that the root cause?
> AvaticaSite.java
> Line 189-199
> public void setTimestamp(Timestamp x, Calendar calendar) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIMESTAMP, x, calendar);
> }
> public void setTime(Time x, Calendar calendar) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIME, x, calendar);
> }
> public void setDate(Date x, Calendar cal) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_DATE, x, calendar);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1371) PreparedStatement does not process Date type correctly
[
https://issues.apache.org/jira/browse/CALCITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1371:
Component/s: (was: core)
avatica
> PreparedStatement does not process Date type correctly
> ---
>
> Key: CALCITE-1371
> URL: https://issues.apache.org/jira/browse/CALCITE-1371
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.8.0
>Reporter: Billy(Yiming) Liu
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> I have problem when passing date parameter in PreparedStatement. Following is
> the sample code:
> TimeZone tzUtc = TimeZone.getTimeZone("UTC");
> Calendar cUtc = Calendar.getInstance(tzUtc);
> cUtc.set(2013, 10, 5, 0, 0, 0);
> java.sql.Date passSqlDate = new java.sql.Date(cUtc.getTimeInMillis());
> statement.setDate(1, passSqlDate, cUtc);
> I try to pass Date'2013/11/5' to the database, but from the debug info I
> found the
> database received '2013/10/4' (GMT -8 Timezone) always. It ignored the
> Calendar I passed in.
> There are some Calcite code a little strange, I have marked by color:
> Why setTimestamp and setTime have effective parameter 'calendar', but setDate
> ignore the
> parameter. Is that the root cause?
> AvaticaSite.java
> Line 189-199
> public void setTimestamp(Timestamp x, Calendar calendar) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIMESTAMP, x, calendar);
> }
> public void setTime(Time x, Calendar calendar) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIME, x, calendar);
> }
> public void setDate(Date x, Calendar cal) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_DATE, x, calendar);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1371) PreparedStatement does not process Date type correctly
[
https://issues.apache.org/jira/browse/CALCITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1371:
Assignee: Billy(Yiming) Liu (was: Julian Hyde)
> PreparedStatement does not process Date type correctly
> ---
>
> Key: CALCITE-1371
> URL: https://issues.apache.org/jira/browse/CALCITE-1371
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.8.0
>Reporter: Billy(Yiming) Liu
>Assignee: Billy(Yiming) Liu
>Priority: Minor
> Fix For: avatica-1.9.0
>
>
> I have problem when passing date parameter in PreparedStatement. Following is
> the sample code:
> TimeZone tzUtc = TimeZone.getTimeZone("UTC");
> Calendar cUtc = Calendar.getInstance(tzUtc);
> cUtc.set(2013, 10, 5, 0, 0, 0);
> java.sql.Date passSqlDate = new java.sql.Date(cUtc.getTimeInMillis());
> statement.setDate(1, passSqlDate, cUtc);
> I try to pass Date'2013/11/5' to the database, but from the debug info I
> found the
> database received '2013/10/4' (GMT -8 Timezone) always. It ignored the
> Calendar I passed in.
> There are some Calcite code a little strange, I have marked by color:
> Why setTimestamp and setTime have effective parameter 'calendar', but setDate
> ignore the
> parameter. Is that the root cause?
> AvaticaSite.java
> Line 189-199
> public void setTimestamp(Timestamp x, Calendar calendar) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIMESTAMP, x, calendar);
> }
> public void setTime(Time x, Calendar calendar) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_TIME, x, calendar);
> }
> public void setDate(Date x, Calendar cal) {
> slots[index] = wrap(ColumnMetaData.Rep.JAVA_SQL_DATE, x, calendar);
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1355) Upgrade to protobuf-java 3.0.0 (stable)
[
https://issues.apache.org/jira/browse/CALCITE-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1519#comment-1519
]
Josh Elser commented on CALCITE-1355:
-
Looks like there is a 3.1.0 now, too.
{quote}
Added UnsafeByteOperations.unsafeWrap(byte[]) to wrap a byte array into
ByteString without copy.
{quote}
This looks like a very interesting API addition.
Stack (over in HBase) also reported an issue with a 64MB limit on message
(https://github.com/google/protobuf/issues/2228). I would guess that we're
already hitting that. Would be good to keep an eye on when the fix makes it
upstream.
> Upgrade to protobuf-java 3.0.0 (stable)
> ---
>
> Key: CALCITE-1355
> URL: https://issues.apache.org/jira/browse/CALCITE-1355
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.9.0
>
>
> Just noticed that protobuf-3.0.0 was released recently.
> https://github.com/google/protobuf/releases/tag/v3.0.0
> We should bump up to that, making sure there aren't any advertised issues
> between the beta version we were using and 3.0.0 (final).
> Marked as blocker against the next Avatica release as having an official
> non-beta protobuf version will help downstream users write more clients
> against Avatica.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1110) remove or relocate shaded jackson in Avatica
[
https://issues.apache.org/jira/browse/CALCITE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1110.
-
Resolution: Duplicate
Marking this as duplicate, but more correctly it is encapsulated by the changes
in CALCITE-1224.
> remove or relocate shaded jackson in Avatica
>
>
> Key: CALCITE-1110
> URL: https://issues.apache.org/jira/browse/CALCITE-1110
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.6.0, 1.5.0
>Reporter: Kai Gülzau
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> The avatica jar includes a shaded version of jackson under the original
> package path.
> This shaded version interferes with other jackson versions in the classpath.
> Currently this prevents us from using jackson functionality which is only
> implemented in newer versions.
> https://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3C977C7450-18F4-48E2-A970-69B7E3E1BD2C%40apache.org%3E
> {quote}
> Is it reasonable to have a maven profile that uses jackson as “provided”[1]
> rather than shading? This would not be the default — the default would be
> continue to use a shaded version of jackson (relocated to
> org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed
> calcite/avatica in a container might appreciate a lighter weight option.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1224) Provide non-shaded and shaded variants of Avatica artifacts
[ https://issues.apache.org/jira/browse/CALCITE-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1224. - Resolution: Fixed Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=e5a42f1ca80eca0bb6f0c8f6677f106fadb2e652 (those watching, I did goof up the commit message and force-pushed to fix it) This also includes a fix for CALCITE-1110 to relocate Jackson in the shaded jar. > Provide non-shaded and shaded variants of Avatica artifacts > --- > > Key: CALCITE-1224 > URL: https://issues.apache.org/jira/browse/CALCITE-1224 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > Kevin Risden started a discussion about problems he using Avatica in certain > environments because of the shaded classes. > https://mail-archives.apache.org/mod_mbox/calcite-dev/201605.mbox/%3CCAJU9nmgcPU9XnFh7RtR%3D4eDZ1Qg25qO0j6xudd_%3Ds89VZ3P1Ag%40mail.gmail.com%3E > After talking it out, we can to the conclusion that providing three things > for Avatica clients should be sufficient for users: > # Provide an avatica client artifact with all dependencies shaded (relocated, > when possible) > # Provide an avatica client artifact with no dependencies shaded > # Provide an example project (e.g. documentatino) users can modify to > construct their own Avatica client artifact with just the dependencies they > desire. > We can't reasonably enumerate all permutations of what might be desired by > users WRT dependency versions, but we can provide them the tools to create > the artifacts they need for their unique environment/deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1385) Support password-based convenience logins for Kerberos-authenticated clients
Josh Elser created CALCITE-1385: --- Summary: Support password-based convenience logins for Kerberos-authenticated clients Key: CALCITE-1385 URL: https://issues.apache.org/jira/browse/CALCITE-1385 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.9.0 Had a request for the automatic Kerberos login process to also support password-based authentication (instead of just keytab). This would require some extra logic in KerberosConnection to do the Jaas Configuration with the provided password, but not attempt to prompt the user for it (as it might be a headless client, like some GUI application). One problem is that GUI apps will likely try to use pass this value in via the "password" key in some properties (in addition to the "user" field). Will actually have to try to test this out to make sure it works as intended. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1291) Incorrect formatting from Avatica in sqlline's table outputformat
[
https://issues.apache.org/jira/browse/CALCITE-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1291:
Fix Version/s: (was: 1.9.0)
> 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
>
> {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] [Commented] (CALCITE-1361) Remove entry from AvaticaConnection.flagMap when session closed
[ https://issues.apache.org/jira/browse/CALCITE-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15437313#comment-15437313 ] Josh Elser commented on CALCITE-1361: - What you have in https://github.com/julianhyde/calcite/commit/9c73c1f7fb9bf639423a638feaa045fe93b332f8#diff-1a64d11e275e3b91d02bfd68b217a991 LGTM. > Remove entry from AvaticaConnection.flagMap when session closed > --- > > Key: CALCITE-1361 > URL: https://issues.apache.org/jira/browse/CALCITE-1361 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > Labels: avatica > Fix For: avatica-1.9.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1364) Bring Docker image for avatica-standalone-server into Apache
[ https://issues.apache.org/jira/browse/CALCITE-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1585#comment-1585 ] Josh Elser commented on CALCITE-1364: - Looks like we have an apache org on docker-hub https://hub.docker.com/r/apache/ I'm not sure how to get things published there though.. > Bring Docker image for avatica-standalone-server into Apache > > > Key: CALCITE-1364 > URL: https://issues.apache.org/jira/browse/CALCITE-1364 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > I worked on making some Docker images for the standalone Avatica Server with > HSQLDB. > https://hub.docker.com/r/joshelser/avatica-hsqldb/ > These greatly simplify running the Avatica TCK and also provide a portable > server that developers can use when testing custom Avatica clients. > For >=1.9.0, we should an image into Avatica (upstream). There are a couple > of open questions on my mind already: > 1. What are the release-ability concerns (do we provide SNAPSHOT Dockerfiles > but not built images as they may be interpreted as "releases")? > 2. What ASF integrations exist (do we need to ask Infra for things?) > 3. Are there any maven plugins we should consider for automation? > (https://github.com/spotify/docker-maven-plugin) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1364) Bring Docker image for avatica-standalone-server into Apache
Josh Elser created CALCITE-1364: --- Summary: Bring Docker image for avatica-standalone-server into Apache Key: CALCITE-1364 URL: https://issues.apache.org/jira/browse/CALCITE-1364 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.9.0 I worked on making some Docker images for the standalone Avatica Server with HSQLDB. https://hub.docker.com/r/joshelser/avatica-hsqldb/ These greatly simplify running the Avatica TCK and also provide a portable server that developers can use when testing custom Avatica clients. For >=1.9.0, we should an image into Avatica (upstream). There are a couple of open questions on my mind already: 1. What are the release-ability concerns (do we provide SNAPSHOT Dockerfiles but not built images as they may be interpreted as "releases")? 2. What ASF integrations exist (do we need to ask Infra for things?) 3. Are there any maven plugins we should consider for automation? (https://github.com/spotify/docker-maven-plugin) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1359) Document how users can log security issues against Calcite and Avatica
[ https://issues.apache.org/jira/browse/CALCITE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15437754#comment-15437754 ] Josh Elser commented on CALCITE-1359: - bq. Is the private list suitable +1 (barring instructions to not do this by the foundation). I think the fine folks at secur...@apache.org would be happy to fwd any reports to our private list. I would think that the PMC is capable of fielding security concerns and bringing to the attention of security@a.o when appropriate (e.g. a CVE is filed, etc) > Document how users can log security issues against Calcite and Avatica > -- > > Key: CALCITE-1359 > URL: https://issues.apache.org/jira/browse/CALCITE-1359 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Apache requires that projects document how to log security issues. Neither > Calcite nor Avatica has that currently. > Dev list and JIRA do not seem appropriate since they are public. Is the > private list suitable? I don't want to create a new list, since the volume of > security issues is very small. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1301) Add cancel flag to AvaticaResultSet
[
https://issues.apache.org/jira/browse/CALCITE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435080#comment-15435080
]
Josh Elser commented on CALCITE-1301:
-
Just left you some comments, [~julianhyde]. I can make the changes if you'd
like and merge it in. Just LMK.
> Add cancel flag to AvaticaResultSet
> ---
>
> Key: CALCITE-1301
> URL: https://issues.apache.org/jira/browse/CALCITE-1301
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Labels: avatica
> Fix For: avatica-1.9.0
>
>
> Add cancel flag to AvaticaResultSet. The flag was added to CalciteResultSet
> as part of CALCITE-1227, but would be useful in the Avatica base class.
> It is currently of type {{CancelFlag}} but maybe it should become
> {{AtomicBoolean}}.
> To complete implementation of java.sql.Statement#cancel we would need a
> Cancel command; that is out of scope of this case, and would be covered by
> CALCITE-520.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1301) Add cancel flag to AvaticaResultSet
[
https://issues.apache.org/jira/browse/CALCITE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435393#comment-15435393
]
Josh Elser commented on CALCITE-1301:
-
bq. The other changes are not part of this bug, but are needed by Calcite for
related stuff, so I thought it would be OK to include them in the same commit.
Ok, great that's fine. I didn't have enough context and thought they were
totally unrelated :)
bq. I think the commit is OK now. If you agree, +1 and I'll squash and push to
master.
Yup. Looks great. Thanks!
> Add cancel flag to AvaticaResultSet
> ---
>
> Key: CALCITE-1301
> URL: https://issues.apache.org/jira/browse/CALCITE-1301
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Labels: avatica
> Fix For: avatica-1.9.0
>
>
> Add cancel flag to AvaticaResultSet. The flag was added to CalciteResultSet
> as part of CALCITE-1227, but would be useful in the Avatica base class.
> It is currently of type {{CancelFlag}} but maybe it should become
> {{AtomicBoolean}}.
> To complete implementation of java.sql.Statement#cancel we would need a
> Cancel command; that is out of scope of this case, and would be covered by
> CALCITE-520.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1301) Add cancel flag to AvaticaResultSet
[
https://issues.apache.org/jira/browse/CALCITE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435398#comment-15435398
]
Josh Elser commented on CALCITE-1301:
-
bq. Yup. Looks great. Thanks!
Actually, it looks like {{flagMap}} is never cleaned up. Is this not a concern?
> Add cancel flag to AvaticaResultSet
> ---
>
> Key: CALCITE-1301
> URL: https://issues.apache.org/jira/browse/CALCITE-1301
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Labels: avatica
> Fix For: avatica-1.9.0
>
>
> Add cancel flag to AvaticaResultSet. The flag was added to CalciteResultSet
> as part of CALCITE-1227, but would be useful in the Avatica base class.
> It is currently of type {{CancelFlag}} but maybe it should become
> {{AtomicBoolean}}.
> To complete implementation of java.sql.Statement#cancel we would need a
> Cancel command; that is out of scope of this case, and would be covered by
> CALCITE-520.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1110) remove or relocate shaded jackson in Avatica
[
https://issues.apache.org/jira/browse/CALCITE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15530715#comment-15530715
]
Josh Elser commented on CALCITE-1110:
-
I'm also addressing this over in CALCITE-1224
https://github.com/apache/calcite/pull/282
> remove or relocate shaded jackson in Avatica
>
>
> Key: CALCITE-1110
> URL: https://issues.apache.org/jira/browse/CALCITE-1110
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.6.0, 1.5.0
>Reporter: Kai Gülzau
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> The avatica jar includes a shaded version of jackson under the original
> package path.
> This shaded version interferes with other jackson versions in the classpath.
> Currently this prevents us from using jackson functionality which is only
> implemented in newer versions.
> https://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3C977C7450-18F4-48E2-A970-69B7E3E1BD2C%40apache.org%3E
> {quote}
> Is it reasonable to have a maven profile that uses jackson as “provided”[1]
> rather than shading? This would not be the default — the default would be
> continue to use a shaded version of jackson (relocated to
> org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed
> calcite/avatica in a container might appreciate a lighter weight option.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1399) SerializationConverter in HsqldbServer needs to be public
Josh Elser created CALCITE-1399:
---
Summary: SerializationConverter in HsqldbServer needs to be public
Key: CALCITE-1399
URL: https://issues.apache.org/jira/browse/CALCITE-1399
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: avatica-1.8.0
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Trivial
Fix For: avatica-1.9.0
The standalone Avatica server built using HSQLDB has an {{IStringConverter}}
implementation for controlling what Avatica serialization method (JSON or
PROTOBUF) is used.
But, this StringConverter class is private which breaks jcommander as it cannot
access the class and instantiate it.
Need to make it public.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1399) SerializationConverter in HsqldbServer needs to be public
[
https://issues.apache.org/jira/browse/CALCITE-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1399.
-
Resolution: Fixed
Resolved in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=c9ec5c88dd46e2c49ec3137d835b086708fbc4d6
> SerializationConverter in HsqldbServer needs to be public
> -
>
> Key: CALCITE-1399
> URL: https://issues.apache.org/jira/browse/CALCITE-1399
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.9.0
>
>
> The standalone Avatica server built using HSQLDB has an {{IStringConverter}}
> implementation for controlling what Avatica serialization method (JSON or
> PROTOBUF) is used.
> But, this StringConverter class is private which breaks jcommander as it
> cannot access the class and instantiate it.
> Need to make it public.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1390) Properties object is modified by Avatica JDBC Driver
[
https://issues.apache.org/jira/browse/CALCITE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1390.
-
Resolution: Fixed
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=8aa11626ea3e87ec4f06bc383eb452a77cc695e5.
Thanks for letting us know about the issue, [~prabhjyotsi...@apache.com].
> Properties object is modified by Avatica JDBC Driver
>
>
> Key: CALCITE-1390
> URL: https://issues.apache.org/jira/browse/CALCITE-1390
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Prabhjyot Singh
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Creating this JIRA from mail thread
> https://lists.apache.org/thread.html/5029f1f09c95a76b6e60a0f80e6f145dedf0b51cfdc08b964fb3b060@%3Cuser.phoenix.apache.org%3E
> I'm using DriverManager.getConnection(url, properties) using following
> properties
> {code}
> url -> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> {code}
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@1491} "user" -> "phoenixuser"
> 1 = {java.util.Hashtable$Entry@1492} "password" ->
> 2 = {java.util.Hashtable$Entry@1493} "url" ->
> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> 3 = {java.util.Hashtable$Entry@1494} "hbase.client.retries.number" -> "4"
> 4 = {java.util.Hashtable$Entry@1495} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> With the above propert/setting/config it returns a connection to the URL
> specified, but it also modifies my properties object to following
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@2361} "serialization" -> "PROTOBUF"
> 1 = {java.util.Hashtable$Entry@2362} "user" -> "phoenixuser"
> 2 = {java.util.Hashtable$Entry@2363} "password" ->
> *3 = {java.util.Hashtable$Entry@2364} "url" ->
> "http://prabhu-3.novalocal:8765 "*
> 4 = {java.util.Hashtable$Entry@2365} "hbase.client.retries.number" -> "4"
> 5 = {java.util.Hashtable$Entry@2366} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> The above only happens if I'm using *thin-client*. Is this the expected
> behaviour ?
> I plan to use this "properties" object after getting the connection for
> something else.
> Also, I'm using following in my maven dependency
> "org.apache.phoenix:phoenix-server-client:4.7.0-HBase-1.1"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Moved] (CALCITE-1390) property object is being modified
[
https://issues.apache.org/jira/browse/CALCITE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser moved PHOENIX-3315 to CALCITE-1390:
--
Fix Version/s: (was: 4.9.0)
avatica-1.9.0
Workflow: jira (was: no-reopen-closed, patch-avail)
Key: CALCITE-1390 (was: PHOENIX-3315)
Project: Calcite (was: Phoenix)
> property object is being modified
> -
>
> Key: CALCITE-1390
> URL: https://issues.apache.org/jira/browse/CALCITE-1390
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Prabhjyot Singh
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Creating this JIRA from mail thread
> https://lists.apache.org/thread.html/5029f1f09c95a76b6e60a0f80e6f145dedf0b51cfdc08b964fb3b060@%3Cuser.phoenix.apache.org%3E
> I'm using DriverManager.getConnection(url, properties) using following
> properties
> {code}
> url -> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> {code}
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@1491} "user" -> "phoenixuser"
> 1 = {java.util.Hashtable$Entry@1492} "password" ->
> 2 = {java.util.Hashtable$Entry@1493} "url" ->
> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> 3 = {java.util.Hashtable$Entry@1494} "hbase.client.retries.number" -> "4"
> 4 = {java.util.Hashtable$Entry@1495} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> With the above propert/setting/config it returns a connection to the URL
> specified, but it also modifies my properties object to following
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@2361} "serialization" -> "PROTOBUF"
> 1 = {java.util.Hashtable$Entry@2362} "user" -> "phoenixuser"
> 2 = {java.util.Hashtable$Entry@2363} "password" ->
> *3 = {java.util.Hashtable$Entry@2364} "url" ->
> "http://prabhu-3.novalocal:8765 "*
> 4 = {java.util.Hashtable$Entry@2365} "hbase.client.retries.number" -> "4"
> 5 = {java.util.Hashtable$Entry@2366} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> The above only happens if I'm using *thin-client*. Is this the expected
> behaviour ?
> I plan to use this "properties" object after getting the connection for
> something else.
> Also, I'm using following in my maven dependency
> "org.apache.phoenix:phoenix-server-client:4.7.0-HBase-1.1"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1390) property object is being modified
[
https://issues.apache.org/jira/browse/CALCITE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527149#comment-15527149
]
Josh Elser commented on CALCITE-1390:
-
Looks like this is happening (depending on how your look at it) with
{{UnregisteredDriver#connect(String, Properties)}} not copying the properties
or {{ConnectStringParser#parse(String, Properties)}} altering the properties
that were passed in.
I think changing {{ConnectStringParser#parseInternal(Properties)}} to make a
copy of the properties that are passed in would be a simple fix.
> property object is being modified
> -
>
> Key: CALCITE-1390
> URL: https://issues.apache.org/jira/browse/CALCITE-1390
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Prabhjyot Singh
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Creating this JIRA from mail thread
> https://lists.apache.org/thread.html/5029f1f09c95a76b6e60a0f80e6f145dedf0b51cfdc08b964fb3b060@%3Cuser.phoenix.apache.org%3E
> I'm using DriverManager.getConnection(url, properties) using following
> properties
> {code}
> url -> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> {code}
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@1491} "user" -> "phoenixuser"
> 1 = {java.util.Hashtable$Entry@1492} "password" ->
> 2 = {java.util.Hashtable$Entry@1493} "url" ->
> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> 3 = {java.util.Hashtable$Entry@1494} "hbase.client.retries.number" -> "4"
> 4 = {java.util.Hashtable$Entry@1495} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> With the above propert/setting/config it returns a connection to the URL
> specified, but it also modifies my properties object to following
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@2361} "serialization" -> "PROTOBUF"
> 1 = {java.util.Hashtable$Entry@2362} "user" -> "phoenixuser"
> 2 = {java.util.Hashtable$Entry@2363} "password" ->
> *3 = {java.util.Hashtable$Entry@2364} "url" ->
> "http://prabhu-3.novalocal:8765 "*
> 4 = {java.util.Hashtable$Entry@2365} "hbase.client.retries.number" -> "4"
> 5 = {java.util.Hashtable$Entry@2366} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> The above only happens if I'm using *thin-client*. Is this the expected
> behaviour ?
> I plan to use this "properties" object after getting the connection for
> something else.
> Also, I'm using following in my maven dependency
> "org.apache.phoenix:phoenix-server-client:4.7.0-HBase-1.1"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1390) property object is being modified
[
https://issues.apache.org/jira/browse/CALCITE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527154#comment-15527154
]
Josh Elser commented on CALCITE-1390:
-
bq. The above only happens if I'm using thin-client. Is this the expected
behaviour ?
And yes, this expected. The options passed in via the URL to DriverManager are
added to the properties. You just should not be seeing this as the caller.
> property object is being modified
> -
>
> Key: CALCITE-1390
> URL: https://issues.apache.org/jira/browse/CALCITE-1390
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Prabhjyot Singh
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Creating this JIRA from mail thread
> https://lists.apache.org/thread.html/5029f1f09c95a76b6e60a0f80e6f145dedf0b51cfdc08b964fb3b060@%3Cuser.phoenix.apache.org%3E
> I'm using DriverManager.getConnection(url, properties) using following
> properties
> {code}
> url -> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> {code}
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@1491} "user" -> "phoenixuser"
> 1 = {java.util.Hashtable$Entry@1492} "password" ->
> 2 = {java.util.Hashtable$Entry@1493} "url" ->
> "jdbc:phoenix:thin:url=http://prabhu-3.novalocal:8765;serialization
> =PROTOBUF"
> 3 = {java.util.Hashtable$Entry@1494} "hbase.client.retries.number" -> "4"
> 4 = {java.util.Hashtable$Entry@1495} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> With the above propert/setting/config it returns a connection to the URL
> specified, but it also modifies my properties object to following
> {code}
> properties ->
> 0 = {java.util.Hashtable$Entry@2361} "serialization" -> "PROTOBUF"
> 1 = {java.util.Hashtable$Entry@2362} "user" -> "phoenixuser"
> 2 = {java.util.Hashtable$Entry@2363} "password" ->
> *3 = {java.util.Hashtable$Entry@2364} "url" ->
> "http://prabhu-3.novalocal:8765 "*
> 4 = {java.util.Hashtable$Entry@2365} "hbase.client.retries.number" -> "4"
> 5 = {java.util.Hashtable$Entry@2366} "driver" ->
> "org.apache.phoenix.jdbc.PhoenixDriver"
> {code}
> The above only happens if I'm using *thin-client*. Is this the expected
> behaviour ?
> I plan to use this "properties" object after getting the connection for
> something else.
> Also, I'm using following in my maven dependency
> "org.apache.phoenix:phoenix-server-client:4.7.0-HBase-1.1"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1224) Provide non-shaded and shaded variants of Avatica artifacts
[ https://issues.apache.org/jira/browse/CALCITE-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15524927#comment-15524927 ] Josh Elser commented on CALCITE-1224: - Just put together a quick PR which will provide both shaded and unshaded Avatica "client" artifacts. Outlined a few thigns that still need to be verified before the change can be merged in, but hopefully I can knock those out easy-peasy tmrw. > Provide non-shaded and shaded variants of Avatica artifacts > --- > > Key: CALCITE-1224 > URL: https://issues.apache.org/jira/browse/CALCITE-1224 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > Kevin Risden started a discussion about problems he using Avatica in certain > environments because of the shaded classes. > https://mail-archives.apache.org/mod_mbox/calcite-dev/201605.mbox/%3CCAJU9nmgcPU9XnFh7RtR%3D4eDZ1Qg25qO0j6xudd_%3Ds89VZ3P1Ag%40mail.gmail.com%3E > After talking it out, we can to the conclusion that providing three things > for Avatica clients should be sufficient for users: > # Provide an avatica client artifact with all dependencies shaded (relocated, > when possible) > # Provide an avatica client artifact with no dependencies shaded > # Provide an example project (e.g. documentatino) users can modify to > construct their own Avatica client artifact with just the dependencies they > desire. > We can't reasonably enumerate all permutations of what might be desired by > users WRT dependency versions, but we can provide them the tools to create > the artifacts they need for their unique environment/deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1405) Create HTML landing page for Avatica
Josh Elser created CALCITE-1405: --- Summary: Create HTML landing page for Avatica Key: CALCITE-1405 URL: https://issues.apache.org/jira/browse/CALCITE-1405 Project: Calcite Issue Type: New Feature Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Minor People seem to be unable to disassociate Avatica being an HTTP server but not serving HTML. Since it would be difficult to train people to not do this anymore, we can create a simple landing page thay describes the Avatica Server (maybe with some generic info about the server). This would make the user experience a bit nicer (people don't get an ugly 404 in their browser). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1469) QueryServer trims Char type padded spaces
[ https://issues.apache.org/jira/browse/CALCITE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608928#comment-15608928 ] Josh Elser commented on CALCITE-1469: - Tagged this one as affectsVersion=1.6.0 (I think that's what we shipped in Phoenix 4.5.2). Any help in writing a test to verify what Avatica is doing would be a great first step. > QueryServer trims Char type padded spaces > - > > Key: CALCITE-1469 > URL: https://issues.apache.org/jira/browse/CALCITE-1469 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.6.0 > Environment: HDP2.3 > Phoenix4.5.2 >Reporter: Hai Fu Yu >Assignee: Josh Elser >Priority: Minor > > Query server is trimming padded spaces on Char type data and it convert back > to fixed length in the client side. > This is unexpected to us as common database would likely return fixed-length > data in fixed length. Is this intentional for reducing network traffic? It > would be great if we could disable auto-trimming on the queryServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1469) QueryServer trims Char type padded spaces
[ https://issues.apache.org/jira/browse/CALCITE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1469: Affects Version/s: 1.6.0 > QueryServer trims Char type padded spaces > - > > Key: CALCITE-1469 > URL: https://issues.apache.org/jira/browse/CALCITE-1469 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.6.0 > Environment: HDP2.3 > Phoenix4.5.2 >Reporter: Hai Fu Yu >Assignee: Josh Elser >Priority: Minor > > Query server is trimming padded spaces on Char type data and it convert back > to fixed length in the client side. > This is unexpected to us as common database would likely return fixed-length > data in fixed length. Is this intentional for reducing network traffic? It > would be great if we could disable auto-trimming on the queryServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1469) QueryServer trims Char type padded spaces
[ https://issues.apache.org/jira/browse/CALCITE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1469: Component/s: avatica > QueryServer trims Char type padded spaces > - > > Key: CALCITE-1469 > URL: https://issues.apache.org/jira/browse/CALCITE-1469 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.6.0 > Environment: HDP2.3 > Phoenix4.5.2 >Reporter: Hai Fu Yu >Assignee: Josh Elser >Priority: Minor > > Query server is trimming padded spaces on Char type data and it convert back > to fixed length in the client side. > This is unexpected to us as common database would likely return fixed-length > data in fixed length. Is this intentional for reducing network traffic? It > would be great if we could disable auto-trimming on the queryServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Moved] (CALCITE-1469) QueryServer trims Char type padded spaces
[ https://issues.apache.org/jira/browse/CALCITE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser moved PHOENIX-2322 to CALCITE-1469: -- Affects Version/s: (was: 4.5.2) Workflow: jira (was: no-reopen-closed, patch-avail) Issue Type: Bug (was: Improvement) Key: CALCITE-1469 (was: PHOENIX-2322) Project: Calcite (was: Phoenix) > QueryServer trims Char type padded spaces > - > > Key: CALCITE-1469 > URL: https://issues.apache.org/jira/browse/CALCITE-1469 > Project: Calcite > Issue Type: Bug > Components: avatica > Environment: HDP2.3 > Phoenix4.5.2 >Reporter: Hai Fu Yu >Assignee: Josh Elser >Priority: Minor > > Query server is trimming padded spaces on Char type data and it convert back > to fixed length in the client side. > This is unexpected to us as common database would likely return fixed-length > data in fixed length. Is this intentional for reducing network traffic? It > would be great if we could disable auto-trimming on the queryServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1470) HttpServerSpnegoWithJaasTest fails on Windows
Josh Elser created CALCITE-1470:
---
Summary: HttpServerSpnegoWithJaasTest fails on Windows
Key: CALCITE-1470
URL: https://issues.apache.org/jira/browse/CALCITE-1470
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Aaron Mihalik
Fix For: avatica-1.10.0
{noformat}
Failed tests:
HttpServerSpnegoWithJaasTest.testAuthenticatedClientsAllowed:223
expected:<[OK cli...@example.com]> but was:<[
Error 500
HTTP ERROR: 500
Problem accessing /. Reason:
Unauthenticated users should not reach here!
Powered by Jetty://
]>
A related error may be:
GSSException: Failure unspecified at GSS-API level (Mechanism level:
Invalid argument (400) - Cannot find key of appropriate type to decrypt AP
REP - AES128 CTS mode with HMAC SHA1-96)
at
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
{noformat}
{noformat}
The key line in the debug out was the "Found KeyTab" line below:
SpNegoContext.initSecContext: sending token of type = SPNEGO NegTokenInit
SNegoContext.initSecContext: sending token = a0 82 ...
Found KeyTab C:Users mihalik empcalcite vaticaserver
argetHttpServerSpnegoWithJaasTest_keytabsHTTP_localhost.keytab
for HTTP/localh...@example.com
Entered SpNegoContext.acceptSecContext with state=STATE_NEW
SpNegoContext.acceptSecContext: receiving token = a0 82 ...
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.113554.1.2.2
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1487) Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after authentication failure
[
https://issues.apache.org/jira/browse/CALCITE-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652160#comment-15652160
]
Josh Elser commented on CALCITE-1487:
-
Relevant code snippets:
https://github.com/apache/calcite/blob/master/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaJsonHandler.java#L93-L97
https://github.com/apache/calcite/blob/master/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaProtobufHandler.java#L95-L99
> Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after
> authentication failure
> -
>
> Key: CALCITE-1487
> URL: https://issues.apache.org/jira/browse/CALCITE-1487
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
> Labels: beginner
> Fix For: avatica-1.10.0
>
>
> I'm looking into a case where there are some authentication issues into an
> Avatica server. The SPNEGO handshake obviously failed via error in the
> server, but the client ultimately saw an HTTP/404 error which doesn't make
> sense (they should see a 401 or 403).
> I think I see why this happens. In the handlers, when the server is
> configured to require authenticated users and a user is not authenticated,
> the {{handle()}} method just returns.
> I believe the Handler implementation should set the Request as handled and
> set the appropriate response code. I believe the 404 is coming from the
> DefaultHandler (which has no html to serve for requests to "/").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1487) Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after authentication failure
Josh Elser created CALCITE-1487:
---
Summary: Avatica{Json,Protobuf}Handler inadvertently returns
HTTP/404 after authentication failure
Key: CALCITE-1487
URL: https://issues.apache.org/jira/browse/CALCITE-1487
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Fix For: avatica-1.10.0
I'm looking into a case where there are some authentication issues into an
Avatica server. The SPNEGO handshake obviously failed via error in the server,
but the client ultimately saw an HTTP/404 error which doesn't make sense (they
should see a 401 or 403).
I think I see why this happens. In the handlers, when the server is configured
to require authenticated users and a user is not authenticated, the
{{handle()}} method just returns.
I believe the Handler implementation should set the Request as handled and set
the appropriate response code. I believe the 404 is coming from the
DefaultHandler (which has no html to serve for requests to "/").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1441) DOUBLE is returned as BigDecimal with JSON serialization
Josh Elser created CALCITE-1441: --- Summary: DOUBLE is returned as BigDecimal with JSON serialization Key: CALCITE-1441 URL: https://issues.apache.org/jira/browse/CALCITE-1441 Project: Calcite Issue Type: Bug Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.9.0 Noticed in my testing for ARRAY support: Serializing a DOUBLE results in Jackson using BigDecimal. This type is directly returned to the user instead of being correctly returned as a Double per the JDBC 4.1 specification, Table B-1: "JDBC Types Mapped to Java Types" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1050) Avatica can't serialize java.sql.Array
[ https://issues.apache.org/jira/browse/CALCITE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1050: Fix Version/s: (was: 1.10.0) avatica-1.10.0 > 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 > Fix For: avatica-1.10.0 > > > 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] [Updated] (CALCITE-1050) Avatica can't serialize java.sql.Array
[ https://issues.apache.org/jira/browse/CALCITE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1050: Fix Version/s: 1.10.0 > 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 > Fix For: avatica-1.10.0 > > > 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] [Created] (CALCITE-1462) Remove unused dependencies in dependencyManagement
Josh Elser created CALCITE-1462: --- Summary: Remove unused dependencies in dependencyManagement Key: CALCITE-1462 URL: https://issues.apache.org/jira/browse/CALCITE-1462 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Blocker Fix For: avatica-1.9.0 I'm noticing a few dependencies listed in management which avatica doesn't actually use. We should remove this cruft as it's just misleading to those reading the pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1462) Remove unused dependencies in dependencyManagement
[ https://issues.apache.org/jira/browse/CALCITE-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1462. - Resolution: Fixed Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=483b9f92359421675a673561c5c317960b6deefb > Remove unused dependencies in dependencyManagement > -- > > Key: CALCITE-1462 > URL: https://issues.apache.org/jira/browse/CALCITE-1462 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Blocker > Fix For: avatica-1.9.0 > > > I'm noticing a few dependencies listed in management which avatica doesn't > actually use. We should remove this cruft as it's just misleading to those > reading the pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1355) Upgrade to protobuf-java 3.1.0 (stable)
[ https://issues.apache.org/jira/browse/CALCITE-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1355. - Resolution: Fixed Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=221d1804cb52a19a63968c718fe662ae64ea12d2 > Upgrade to protobuf-java 3.1.0 (stable) > --- > > Key: CALCITE-1355 > URL: https://issues.apache.org/jira/browse/CALCITE-1355 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Blocker > Fix For: avatica-1.9.0 > > > Just noticed that protobuf-3.0.0 was released recently. > https://github.com/google/protobuf/releases/tag/v3.0.0 > We should bump up to that, making sure there aren't any advertised issues > between the beta version we were using and 3.0.0 (final). > Marked as blocker against the next Avatica release as having an official > non-beta protobuf version will help downstream users write more clients > against Avatica. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1463) Remove exclusions from standalone-server's shaded jar
[ https://issues.apache.org/jira/browse/CALCITE-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1463. - Resolution: Fixed Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=2438d53e58e0992b2ab9cc45d1fd631b8bcffec5 > Remove exclusions from standalone-server's shaded jar > - > > Key: CALCITE-1463 > URL: https://issues.apache.org/jira/browse/CALCITE-1463 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Blocker > Fix For: avatica-1.9.0 > > > More fallout from the non-shaded+shaded client changes in CALCITE-1224. > The standalone-server's shaded jar was excluding some dependencies already > present because it only provided the shaded jar. When switching it to use the > non-shaded artifact, the exclusions should have been removed and they were > not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1464) Upgrade dependencies to latest in their maintenance lines
[
https://issues.apache.org/jira/browse/CALCITE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1464.
-
Resolution: Fixed
Fixed in
https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=2ee0e35aaa20f80b61ea7333eff3d50c2fa94023
> Upgrade dependencies to latest in their maintenance lines
> -
>
> Key: CALCITE-1464
> URL: https://issues.apache.org/jira/browse/CALCITE-1464
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> {quote}
> * Updating jetty to 9.2.19.v20160908 is probably safe/good to do.
> * -Updating to jodatime 2.9.4 also sounds good-
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1255) Add comment to deprecated method from CALCITE-1243
[ https://issues.apache.org/jira/browse/CALCITE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1255. - Resolution: Fixed This was actually done in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=08c966b9828f534ba3d8d2ccf052de7d887c70ef > Add comment to deprecated method from CALCITE-1243 > -- > > Key: CALCITE-1255 > URL: https://issues.apache.org/jira/browse/CALCITE-1255 > Project: Calcite > Issue Type: New Feature > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.9.0 > > > Need to define when the deprecated method will be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1464) Upgrade dependencies to latest in their maintenance lines
Josh Elser created CALCITE-1464:
---
Summary: Upgrade dependencies to latest in their maintenance lines
Key: CALCITE-1464
URL: https://issues.apache.org/jira/browse/CALCITE-1464
Project: Calcite
Issue Type: Task
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.9.0
{quote}
* Updating jetty to 9.2.19.v20160908 is probably safe/good to do.
* Updating to jodatime 2.9.4 also sounds good
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1464) Upgrade dependencies to latest in their maintenance lines
[
https://issues.apache.org/jira/browse/CALCITE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1464:
Description:
{quote}
* Updating jetty to 9.2.19.v20160908 is probably safe/good to do.
* -Updating to jodatime 2.9.4 also sounds good-
{quote}
was:
{quote}
* Updating jetty to 9.2.19.v20160908 is probably safe/good to do.
* Updating to jodatime 2.9.4 also sounds good
{quote}
> Upgrade dependencies to latest in their maintenance lines
> -
>
> Key: CALCITE-1464
> URL: https://issues.apache.org/jira/browse/CALCITE-1464
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> {quote}
> * Updating jetty to 9.2.19.v20160908 is probably safe/good to do.
> * -Updating to jodatime 2.9.4 also sounds good-
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1463) Remove exclusions from standalone-server's shaded jar
Josh Elser created CALCITE-1463: --- Summary: Remove exclusions from standalone-server's shaded jar Key: CALCITE-1463 URL: https://issues.apache.org/jira/browse/CALCITE-1463 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Blocker Fix For: avatica-1.9.0 More fallout from the non-shaded+shaded client changes in CALCITE-1224. The standalone-server's shaded jar was excluding some dependencies already present because it only provided the shaded jar. When switching it to use the non-shaded artifact, the exclusions should have been removed and they were not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1355) Upgrade to protobuf-java 3.0.0 (stable)
[ https://issues.apache.org/jira/browse/CALCITE-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600205#comment-15600205 ] Josh Elser commented on CALCITE-1355: - I ran a quick compatibility test using Avatica 1.8.0. I was able to verify that, with this protobuf upgrade, we still have forward and backward compatibility (using a simple create+insert+read test) with the earlier protobuf version. As such, I'm going to merge this in. > Upgrade to protobuf-java 3.0.0 (stable) > --- > > Key: CALCITE-1355 > URL: https://issues.apache.org/jira/browse/CALCITE-1355 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Blocker > Fix For: avatica-1.9.0 > > > Just noticed that protobuf-3.0.0 was released recently. > https://github.com/google/protobuf/releases/tag/v3.0.0 > We should bump up to that, making sure there aren't any advertised issues > between the beta version we were using and 3.0.0 (final). > Marked as blocker against the next Avatica release as having an official > non-beta protobuf version will help downstream users write more clients > against Avatica. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1355) Upgrade to protobuf-java 3.1.0 (stable)
[ https://issues.apache.org/jira/browse/CALCITE-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1355: Summary: Upgrade to protobuf-java 3.1.0 (stable) (was: Upgrade to protobuf-java 3.0.0 (stable)) > Upgrade to protobuf-java 3.1.0 (stable) > --- > > Key: CALCITE-1355 > URL: https://issues.apache.org/jira/browse/CALCITE-1355 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Blocker > Fix For: avatica-1.9.0 > > > Just noticed that protobuf-3.0.0 was released recently. > https://github.com/google/protobuf/releases/tag/v3.0.0 > We should bump up to that, making sure there aren't any advertised issues > between the beta version we were using and 3.0.0 (final). > Marked as blocker against the next Avatica release as having an official > non-beta protobuf version will help downstream users write more clients > against Avatica. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1458) ColumnValue not backwards compatibile after CALCITE-1040
[ https://issues.apache.org/jira/browse/CALCITE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1458: Affects Version/s: 1.6.0 avatica-1.8.0 avatica-1.7.1 avatica-1.7.0 > ColumnValue not backwards compatibile after CALCITE-1040 > > > Key: CALCITE-1458 > URL: https://issues.apache.org/jira/browse/CALCITE-1458 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.6.0, avatica-1.8.0, avatica-1.7.1, avatica-1.7.0 >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Blocker > Fix For: avatica-1.9.0 > > > [~onpduo] was nice enough to help me debug an issue using the C# driver > against Avatica 1.8.1. We could see that a record was being placed into the > database, but the C# driver wasn't returning the value. > After inspecting the server, I could see that the row was being returned by > the server. Still the client claimed to not know about the value in the row. > Turns out, this was a botched backwards-compatibility issue introduced by > CALCITE-1040. When the array_value and scalar_value fields were introduced, > the original value field stopped having the values set in it. This caused the > C# driver, which was still using that (now deprecated) field to stop seeing > any records. > A simple fix to start adding the values for the row into that deprecated > field seems to have fixed the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1458) ColumnValue not backwards compatibile after CALCITE-1040
Josh Elser created CALCITE-1458: --- Summary: ColumnValue not backwards compatibile after CALCITE-1040 Key: CALCITE-1458 URL: https://issues.apache.org/jira/browse/CALCITE-1458 Project: Calcite Issue Type: Bug Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Blocker Fix For: avatica-1.9.0 [~onpduo] was nice enough to help me debug an issue using the C# driver against Avatica 1.8.1. We could see that a record was being placed into the database, but the C# driver wasn't returning the value. After inspecting the server, I could see that the row was being returned by the server. Still the client claimed to not know about the value in the row. Turns out, this was a botched backwards-compatibility issue introduced by CALCITE-1040. When the array_value and scalar_value fields were introduced, the original value field stopped having the values set in it. This caused the C# driver, which was still using that (now deprecated) field to stop seeing any records. A simple fix to start adding the values for the row into that deprecated field seems to have fixed the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1458) ColumnValue not backwards compatibile after CALCITE-1040
[ https://issues.apache.org/jira/browse/CALCITE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1458. - Resolution: Fixed Resolved in https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=6010ce10faba4457ffdc0809bff981bebba5237b > ColumnValue not backwards compatibile after CALCITE-1040 > > > Key: CALCITE-1458 > URL: https://issues.apache.org/jira/browse/CALCITE-1458 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.6.0, avatica-1.8.0, avatica-1.7.1, avatica-1.7.0 >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Blocker > Fix For: avatica-1.9.0 > > > [~onpduo] was nice enough to help me debug an issue using the C# driver > against Avatica 1.8.1. We could see that a record was being placed into the > database, but the C# driver wasn't returning the value. > After inspecting the server, I could see that the row was being returned by > the server. Still the client claimed to not know about the value in the row. > Turns out, this was a botched backwards-compatibility issue introduced by > CALCITE-1040. When the array_value and scalar_value fields were introduced, > the original value field stopped having the values set in it. This caused the > C# driver, which was still using that (now deprecated) field to stop seeing > any records. > A simple fix to start adding the values for the row into that deprecated > field seems to have fixed the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1475) Jackson shading causes JsonIgnore to be ignored when serializing response as JSON
[
https://issues.apache.org/jira/browse/CALCITE-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1475:
Attachment: CALCITE-1475.001.patch
[~julianhyde], assuming you already have Calcite primed for the 1.9.0 upgrade,
here's the patch on top of that which should fix the Jackson issue.
> Jackson shading causes JsonIgnore to be ignored when serializing response as
> JSON
> -
>
> Key: CALCITE-1475
> URL: https://issues.apache.org/jira/browse/CALCITE-1475
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
> Attachments: CALCITE-1475.001.patch
>
>
> I am getting an error while running
> {{CalciteRemoteDriverTest.testRemotePrepareExecute}} because Avatica is
> trying to serialize the field {{CalcitePrepare.CalciteSignature.rowType}} to
> JSON. The field has the annotation {{@JsonIgnore}} but I surmise that that
> annotation is being ignored because Jackson is being shaded inside Avatica.
> Here is the error stack:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.type.RelDataTypeImpl.getFieldList(RelDataTypeImpl.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:654)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serializeDynamic(MapEntrySerializer.java:252)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serialize(MapEntrySerializer.java:197)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serialize(MapEntrySerializer.java:19)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serializeContents(IndexedListSerializer.java:119)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:79)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:18)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeWithType(BeanSerializerBase.java:566)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.TypeWrappedSerializer.serialize(TypeWrappedSerializer.java:32)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:130)
> at
>
[jira] [Commented] (CALCITE-1475) Jackson shading causes JsonIgnore to be ignored when serializing response as JSON
[
https://issues.apache.org/jira/browse/CALCITE-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15620636#comment-15620636
]
Josh Elser commented on CALCITE-1475:
-
Ok, I don't think this should be viewed as a regression in Avatica. Let me try
to explain.
This happens now because Calcite uses the "normal" com.fasterxml... package for
jackson classes. The avatica "shaded" jar relocated the jackson classes to
org.apache.calcite.avatica.shaded.com.fasterxml... This discrepancy is the
cause for the breakage. Avatica is looking for the annotation in the relocated
class name, while Calcite is expecting the non-relocated class to be picked up.
IMO, the proper fix is to use the avatica-core dependency in Calcite. Avatica
should not have been distributing a shaded jar to clients with bundled,
non-relocated dependency classes in it; this is flat out bad/wrong. Because
Calcite is using jackson itself, it needs to use the actual dependency, not the
shaded Avatica client (because that dependency should *not* be visible to
Calcite).
If Calcite wants to create a single artifact (based on the calcite-core Maven
module), then it should use the avatica-core module and use the shade plugin to
relocate the dependencies. This would not be an issue as both Avatica and
Calcite would be using Jackson relocated at the same place.
> Jackson shading causes JsonIgnore to be ignored when serializing response as
> JSON
> -
>
> Key: CALCITE-1475
> URL: https://issues.apache.org/jira/browse/CALCITE-1475
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>
> I am getting an error while running
> {{CalciteRemoteDriverTest.testRemotePrepareExecute}} because Avatica is
> trying to serialize the field {{CalcitePrepare.CalciteSignature.rowType}} to
> JSON. The field has the annotation {{@JsonIgnore}} but I surmise that that
> annotation is being ignored because Jackson is being shaded inside Avatica.
> Here is the error stack:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.type.RelDataTypeImpl.getFieldList(RelDataTypeImpl.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:654)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serializeDynamic(MapEntrySerializer.java:252)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serialize(MapEntrySerializer.java:197)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serialize(MapEntrySerializer.java:19)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serializeContents(IndexedListSerializer.java:119)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:79)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:18)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
>
[jira] [Updated] (CALCITE-1471) HttpServerSpnegoWithJaasTest.testAuthenticatedClientsAllowed fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1471:
Assignee: Aaron Mihalik
> HttpServerSpnegoWithJaasTest.testAuthenticatedClientsAllowed fails on Windows
> -
>
> Key: CALCITE-1471
> URL: https://issues.apache.org/jira/browse/CALCITE-1471
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Julian Hyde
>Assignee: Aaron Mihalik
> Fix For: avatica-1.9.0
>
>
> The test {{HttpServerSpnegoWithJaasTest.testAuthenticatedClientsAllowed}}
> fails on Windows, with the following message:
> {noformat}
> Failed tests:
> HttpServerSpnegoWithJaasTest.testAuthenticatedClientsAllowed:223
> expected:<[OK cli...@example.com]> but was:<[
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Unauthenticated users should not reach here!
> Powered by Jetty://
>
>
> ]>
> {noformat}
> Unlike some other SPNEGO tests, this one occurs every time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1470) HttpServerSpnegoWithJaasTest fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1470.
-
Resolution: Duplicate
Fix Version/s: (was: avatica-1.10.0)
See CALCITE-1471
> HttpServerSpnegoWithJaasTest fails on Windows
> -
>
> Key: CALCITE-1470
> URL: https://issues.apache.org/jira/browse/CALCITE-1470
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Aaron Mihalik
>
> {noformat}
> Failed tests:
> HttpServerSpnegoWithJaasTest.testAuthenticatedClientsAllowed:223
> expected:<[OK cli...@example.com]> but was:<[
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Unauthenticated users should not reach here!
> Powered by Jetty://
>
>
> ]>
> A related error may be:
> GSSException: Failure unspecified at GSS-API level (Mechanism level:
> Invalid argument (400) - Cannot find key of appropriate type to decrypt AP
> REP - AES128 CTS mode with HMAC SHA1-96)
> at
> sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> {noformat}
> {noformat}
> The key line in the debug out was the "Found KeyTab" line below:
> SpNegoContext.initSecContext: sending token of type = SPNEGO NegTokenInit
> SNegoContext.initSecContext: sending token = a0 82 ...
> Found KeyTab C:Users mihalik empcalcite vaticaserver
> argetHttpServerSpnegoWithJaasTest_keytabsHTTP_localhost.keytab
> for HTTP/localh...@example.com
> Entered SpNegoContext.acceptSecContext with state=STATE_NEW
> SpNegoContext.acceptSecContext: receiving token = a0 82 ...
> SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.113554.1.2.2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1475) Jackson shading causes JsonIgnore to be ignored when serializing response as JSON
[
https://issues.apache.org/jira/browse/CALCITE-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15619974#comment-15619974
]
Josh Elser commented on CALCITE-1475:
-
[~julianhyde] one change that happened was that Jackson was relocated inside
the shaded jar to prevent classpath issues. Maybe that inadvertently broke this
annotation as well? Shame if it did since the testing didn't uncover this.
I haven't run into this before. I'd have to do some digging to see if I can
figure out what happened.
> Jackson shading causes JsonIgnore to be ignored when serializing response as
> JSON
> -
>
> Key: CALCITE-1475
> URL: https://issues.apache.org/jira/browse/CALCITE-1475
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>
> I am getting an error while running
> {{CalciteRemoteDriverTest.testRemotePrepareExecute}} because Avatica is
> trying to serialize the field {{CalcitePrepare.CalciteSignature.rowType}} to
> JSON. The field has the annotation {{@JsonIgnore}} but I surmise that that
> annotation is being ignored because Jackson is being shaded inside Avatica.
> Here is the error stack:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.type.RelDataTypeImpl.getFieldList(RelDataTypeImpl.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:654)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serializeDynamic(MapEntrySerializer.java:252)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serialize(MapEntrySerializer.java:197)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.MapEntrySerializer.serialize(MapEntrySerializer.java:19)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serializeContents(IndexedListSerializer.java:119)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:79)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:18)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:693)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:675)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeWithType(BeanSerializerBase.java:566)
> at
> org.apache.calcite.avatica.com.fasterxml.jackson.databind.ser.impl.TypeWrappedSerializer.serialize(TypeWrappedSerializer.java:32)
> at
>
[jira] [Commented] (CALCITE-1433) avatica-server module depends on non-existent avatica test-jar
[ https://issues.apache.org/jira/browse/CALCITE-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567387#comment-15567387 ] Josh Elser commented on CALCITE-1433: - Hah, oops! Thanks for catching this, [~laurentgo]. Will try to get this merged in and add you as a contributor. The patch is very much appreciated! > avatica-server module depends on non-existent avatica test-jar > -- > > Key: CALCITE-1433 > URL: https://issues.apache.org/jira/browse/CALCITE-1433 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Laurent Goujon > > Because of CALCITE-1224, avatica artifact was renamed avatica-core (and a new > avatica artifact is produced). Unfortunately, avatica-server still depends on > avatica test-jar, which is now avatica-core test-jar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1433) avatica-server module depends on non-existent avatica test-jar
[ https://issues.apache.org/jira/browse/CALCITE-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1433: Fix Version/s: avatica-1.9.0 > avatica-server module depends on non-existent avatica test-jar > -- > > Key: CALCITE-1433 > URL: https://issues.apache.org/jira/browse/CALCITE-1433 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Laurent Goujon >Assignee: Laurent Goujon > Fix For: avatica-1.9.0 > > > Because of CALCITE-1224, avatica artifact was renamed avatica-core (and a new > avatica artifact is produced). Unfortunately, avatica-server still depends on > avatica test-jar, which is now avatica-core test-jar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
