[jira] [Created] (CALCITE-5129) Exception thrown writing to a closed stream with SPNEGO authentication at DEBUG
Josh Elser created CALCITE-5129:
---
Summary: Exception thrown writing to a closed stream with SPNEGO
authentication at DEBUG
Key: CALCITE-5129
URL: https://issues.apache.org/jira/browse/CALCITE-5129
Project: Calcite
Issue Type: Bug
Reporter: Josh Elser
Assignee: Josh Elser
{noformat}
2022-05-03 18:27:57,651 WARN org.eclipse.jetty.server.HttpChannelState:
unhandled due to prior sendError
org.eclipse.jetty.io.EofException: Closed
at
org.eclipse.jetty.server.HttpOutput.checkWritable(HttpOutput.java:762)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:792)
at java.io.OutputStream.write(OutputStream.java:75)
at
org.apache.calcite.avatica.server.AbstractAvaticaHandler.isUserPermitted(AbstractAvaticaHandler.java:71)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:103)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:59)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:540)
at
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:395)
at
org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:161)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:383)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:882)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1036)
{noformat}
Trying to test CALCITE-4152 behind Apache Knox, I noticed the following in the
server-side logs.
It appears that we end up spitting out an exception when another layer of code
has already called {{sendError()}} which prevents any further writes to the
OutputStream (destined back to the client). I think this is cosmetic, but I'm
not 100% certain at this point.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (CALCITE-4971) update httpclient and httpcore to latest 5.1 release
[ https://issues.apache.org/jira/browse/CALCITE-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-4971. - Fix Version/s: avatica-1.21.0 Resolution: Fixed > update httpclient and httpcore to latest 5.1 release > > > Key: CALCITE-4971 > URL: https://issues.apache.org/jira/browse/CALCITE-4971 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Fix For: avatica-1.21.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Apache commons httpclient/httpcomponent 4.5 depend on commons-logging and not > slf4j. This means that phoenix-thin requires explicit log4j configuration to > work. > We want all logging to go through SLF4j, and to be able to use any supported > backend. > Based on an an offline conversation with [~elserj] > As these are new major version, it's probably going to involve more than a > version bump. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-5082) Ensure client_reference updated on site for user-facing properties
Josh Elser created CALCITE-5082: --- Summary: Ensure client_reference updated on site for user-facing properties Key: CALCITE-5082 URL: https://issues.apache.org/jira/browse/CALCITE-5082 Project: Calcite Issue Type: Task Components: site Reporter: Josh Elser Assignee: Josh Elser In CALCITE-5009 's code review, I noticed that the client reference is out of date. Give it a refresh. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-5009.
-
Fix Version/s: avatica-1.21.0
Resolution: Fixed
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Fix For: avatica-1.21.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, if the server-side JDBC connection goes away because it is expored
> from the server-side connection cache we attempt to transparently create a
> new "real" JDBC connection, and continue using that instead of the original
> connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516071#comment-17516071
]
Josh Elser commented on CALCITE-5009:
-
Of course! I was the one who wrote this apparently half-baked idea :). Happy to
review.
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, if the server-side JDBC connection goes away because it is expored
> from the server-side connection cache we attempt to transparently create a
> new "real" JDBC connection, and continue using that instead of the original
> connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4971) Update org.apache.httpcomponents:httpclient to latest
[ https://issues.apache.org/jira/browse/CALCITE-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468197#comment-17468197 ] Josh Elser commented on CALCITE-4971: - Thanks for filing, Istvan, and thanks for clarifying things, Julian. > Update org.apache.httpcomponents:httpclient to latest > -- > > Key: CALCITE-4971 > URL: https://issues.apache.org/jira/browse/CALCITE-4971 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Priority: Major > > Apache commons httpclient/httpcomponent 4.5 depend on commons-logging and not > slf4j. This means that phoenix-thin requires explicit log4j configuration to > work. > We want all logging to go through SLF4j, and to be able to use any supported > backend. > Based on an an offline conversation with [~elserj] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4933) Release Avatica 1.20.0
[ https://issues.apache.org/jira/browse/CALCITE-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458490#comment-17458490 ] Josh Elser commented on CALCITE-4933: - Julian actually did the work – letting the assignee reflect that :) > Release Avatica 1.20.0 > -- > > Key: CALCITE-4933 > URL: https://issues.apache.org/jira/browse/CALCITE-4933 > Project: Calcite > Issue Type: Task >Reporter: Josh Elser >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Release 1.20 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CALCITE-4933) Release Avatica 1.20.0
[ https://issues.apache.org/jira/browse/CALCITE-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-4933: --- Assignee: Julian Hyde (was: Josh Elser) > Release Avatica 1.20.0 > -- > > Key: CALCITE-4933 > URL: https://issues.apache.org/jira/browse/CALCITE-4933 > Project: Calcite > Issue Type: Task >Reporter: Josh Elser >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Release 1.20 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457795#comment-17457795 ] Josh Elser commented on CALCITE-4935: - The point of the standalone server jar was to give you a way to launch avatica against any database via a "java -cp" command. It makes testing Julian's hsqdb Scott dataset easy, for example. Removing the relocation for slf4j and log4j were to avoid needing to make extra implementations to use standard logger configuration. I don't remember why I had to undo it for Jetty too (but I imagine it was broken). If we do relocate them, we'll have to do the relocation like Stamatis said and also document how you change the logging config. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4933) Release avatica 1.20
Josh Elser created CALCITE-4933: --- Summary: Release avatica 1.20 Key: CALCITE-4933 URL: https://issues.apache.org/jira/browse/CALCITE-4933 Project: Calcite Issue Type: Task Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.20.0 Release 1.20 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-1244) `offset` is ignored in FetchRequest
[
https://issues.apache.org/jira/browse/CALCITE-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1244:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.0)
> `offset` is ignored in FetchRequest
> ---
>
> Key: CALCITE-1244
> URL: https://issues.apache.org/jira/browse/CALCITE-1244
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Priority: Major
> Fix For: avatica-1.21.0
>
>
> In looking into some issues reported by [~onpduo], we both noticed that
> {{FetchRequest.offset}} is never actually used by the server.
> We should make sure the semantics on this value are clear (is it an offset
> from the beginning of the ResultSet or the current position of the
> ResultSet?) and make sure it is used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-839) Remove Jackson annotations from POJO classes in Meta
[ https://issues.apache.org/jira/browse/CALCITE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-839: --- Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Remove Jackson annotations from POJO classes in Meta > > > Key: CALCITE-839 > URL: https://issues.apache.org/jira/browse/CALCITE-839 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.21.0 > > > The Meta interface contains several POJO classes that represent RPC requests > or responses. Currently a few of those classes have Jackson annotations such > as @JsonCreator, @JsonProperty to help Jackson serialize the POJO to JSON and > de-serialize from JSON to the object. > As [~ndimiduk] pointed out in > http://mail-archives.apache.org/mod_mbox/calcite-dev/201503.mbox/%3CCANZa=gvkgd+bkj4+ejmuo6ivhs+okgskg1vwdazcy-zijyy...@mail.gmail.com%3E > these annotations are a "code smell" and should be removed. It makes it look > as if Jackson is the only possible transport, which is not the case. We can > continue to use Jackson as a transport, just specify the mappings elsewhere, > not as annotations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1242: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Allow configuration of maximum allowed value for maxRowCount > > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.21.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-1811) Work around "latest" tag for Docker images
[
https://issues.apache.org/jira/browse/CALCITE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1811:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.0)
> Work around "latest" tag for Docker images
> --
>
> Key: CALCITE-1811
> URL: https://issues.apache.org/jira/browse/CALCITE-1811
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.10.0
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.21.0
>
>
> One wrinkle with the dockerhub integration with the ASF is that we only get a
> tag for the explicit version we released (e.g. 1.10.0).
> However, in the other Dockerfiles we have in the 1.10.0 release, I had
> (incorrectly) relied on that. Need to come up with a plan for how to better
> manage this in the future. I think that we need to just have {{FROM
> apache/calcite-avatica:$tag}} everywhere, relying on the parent eventually
> being published to dockerhub by the ASF infra.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-1385) Support password-based convenience logins for Kerberos-authenticated clients
[ https://issues.apache.org/jira/browse/CALCITE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1385: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > 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 >Priority: Major > Fix For: avatica-1.21.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 (v8.20.1#820001)
[jira] [Updated] (CALCITE-1928) Calling previous() on a ResultSet that came from an Array gives NullPointerException
[ https://issues.apache.org/jira/browse/CALCITE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1928: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Calling previous() on a ResultSet that came from an Array gives > NullPointerException > > > Key: CALCITE-1928 > URL: https://issues.apache.org/jira/browse/CALCITE-1928 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.21.0 > > > Calling previous() on a ResultSet that came from an Array gives > NullPointerException. I broke this when I committed CALCITE-1902 and changed > 'Helper.INSTANCE' to 'statement.connection.helper', forgetting that > 'statement' can be null. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-1316) Better control over retried operations in Avatica client
[ https://issues.apache.org/jira/browse/CALCITE-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1316: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > 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 >Priority: Major > Fix For: avatica-1.21.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 (v8.20.1#820001)
[jira] [Updated] (CALCITE-3162) Reading Arrays from Calcite through JdbcMeta generates AvaticaSqlException
[
https://issues.apache.org/jira/browse/CALCITE-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-3162:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.0)
> Reading Arrays from Calcite through JdbcMeta generates AvaticaSqlException
> --
>
> Key: CALCITE-3162
> URL: https://issues.apache.org/jira/browse/CALCITE-3162
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.15.0
> Environment: Tested on OS X 10.14.5, OpenJDK Runtime Environment
> Zulu11.29+3-CA (build 11.0.2+7-LTS)
> Issue occurs with both Apache Calcite 1.19.0 & 1.20.0.
>Reporter: Ralph Gasser
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.21.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm trying to use _Apache Calcite_ as SQL Parser and Query Planner for a
> custom data store and in addition, I'm using _Apache Avatica_ to expose the
> entire functionality via JDBC for an arbitrary, potential remote client to
> use.
> We're working a lot with Array types, since we're using our backend to store
> high-dimensional vectors. However, it seems that currently, Apache Avatica
> has troubles handling such arrays.
> Take the following test-case that reproduces the problem pretty well.
> {code:java}
> @Test
> public void test() throws Exception {
> HttpServer server = null;
> try {
> Class.forName("org.apache.calcite.jdbc.Driver");
> server = new HttpServer.Builder<>()
> .withHandler(new LocalService(new JdbcMeta("jdbc:calcite:",
> newProperties())),Driver.Serialization.PROTOBUF)
> .withPort(1234)
> .build();
> server.start();
> final Connection connection =
> DriverManager.getConnection("jdbc:avatica:remote:serialization=protobuf;url=http://127.0.0.1:1234;);
> final Statement stmt = connection.createStatement();
> final ResultSet resultSet = stmt.executeQuery("select ARRAY[1.0, 1.0,
> 3.0, 2.0]");
> resultSet.next();
> resultSet.getArray(1);
> } catch (Exception e) {
> System.out.println(e.getMessage());
> } finally {
> if (server != null) {
>server.stop();
> }
> }
> }
> {code}
> Executing the statement will throw an AvaticaSqlException:
> {code:java}
> org.apache.calcite.avatica.AvaticaSqlException: Error -1 (0) : Error
> while executing SQL "select ARRAY[1.0, 1.0, 3.0, 2.0]": Remote driver error:
> RuntimeException: java.sql.SQLException: invalid column ordinal: 2 ->
> SQLException: invalid column ordinal: 2
> {code}
> The culprit seems to be the _org.apache.calcite.avatica.jdbc.JdbcResultSet_
> class. More specifically, the _JdbcResultSet#extractUsingResultSet()_ method.
> I am actually testing a potential fix but first I wanted to make sure, that
> there is nothing wrong with the way I'm using the two components.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-2983) Add Avatica compatibility page for TLS and IBM Java
[ https://issues.apache.org/jira/browse/CALCITE-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-2983: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Add Avatica compatibility page for TLS and IBM Java > --- > > Key: CALCITE-2983 > URL: https://issues.apache.org/jira/browse/CALCITE-2983 > Project: Calcite > Issue Type: Task > Components: avatica, site >Reporter: Kevin Risden >Priority: Major > Fix For: avatica-1.21.0 > > > With the Jetty upgrade in CALCITE-2972, there are some compatibility issues > between TLS support and IBM Java. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[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: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Implement remaining DatabaseMetaData operations in RemoteMeta > - > > Key: CALCITE-1308 > URL: https://issues.apache.org/jira/browse/CALCITE-1308 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.21.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 (v8.20.1#820001)
[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.21.0
(was: avatica-1.20.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.21.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
(v8.20.1#820001)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
https://issues.apache.org/jira/browse/CALCITE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1341:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.0)
> Improve mechanism for client/server to unwrap protobuf RPC message
> --
>
> Key: CALCITE-1341
> URL: https://issues.apache.org/jira/browse/CALCITE-1341
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.21.0
>
>
> We just ran into a funny bug in PHOENIX-3136 as a fallout of some changes
> which relocated Avatica classes.
> Because the Avatica RPC classes were also relocated (from
> org.apache.calcite.avatica to org.apache.phoenix.org.apache.calcite.avatica),
> clients of an older version could no longer communicate with a server of the
> newer version (and vice versa). This stems from a decision made where the
> wire API included the class name of the Request and Response Java protobuf
> class in the message. The server would send back the Response class name with
> the relocated name, but the client would not know what that class is (because
> it doesn't have the same relocation). In other words, the current protobuf
> serialization approach requires that Avatica classes are not shaded and
> relocated.
> The JSON serialization doesn't have this problem because it uses the
> {{JsonSubType}} Jackson annotation to map the Request/Response class to a
> logical name (e.g. OpenConnectionResponse to openConnection).
> We could do a similar approach for protobuf that the JSON serialization does
> (maintain this mapping and guarantee that it is not changed incompatibly).
> Long-term, I believe I'd like to see specific Requests dispatched to certain
> URLs (instead of all HTTP requests send to {{/}}) and do away with this
> additional logic in the serialization layer, but I'm not sure if we have to
> re-architect the URL scheme just to fix this issue in the near-term.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-1318) Build/Document Avatica Kerberos/SPNEGO authentication behind load balancer.
[ https://issues.apache.org/jira/browse/CALCITE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1318: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Build/Document Avatica Kerberos/SPNEGO authentication behind load balancer. > --- > > Key: CALCITE-1318 > URL: https://issues.apache.org/jira/browse/CALCITE-1318 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.21.0 > > > I was talking with [~_alexm] this weekend about some work that he had > recently done in getting Apache Impala set up behind a load balancer. When > Kerberos is in the picture, he told me that the way that works is that the > impalad daemons actually have two Kerberos identities: one for the hostname > that the impalad service is actually running on and another for the load > balancer host. The load-balancer continues to just do a simple pass-through. > Right now, the Avatica server can only accept a single Kerberos > principal+keytab. This means that we can't use the Kerberos authentication > when the client can access the server via multiple hostnames -- invalidating > the use of 'dumb' load balancers (hypothetically, a smart loadbalancer could > make it work). We could configure the Avatica server to use a principal with > the load-balancer's hostname, but then users would be unable to connect > directly to the server. > I know that Impala uses (or at least exposes) Thrift which has its own SASL > implementation; maybe they do something tricky there? Maybe we can glean > something from their implementation (even though it's not HTTP based). I > don't think JAAS lets us have multiple active logins, so I'm not even sure > where to begin. > Ideally, this is something that would be great to understand and provide some > deployment guidance for users to have identical deployment scenario for > "secure" and "unsecure" scenarios. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-1164) Use setObject(int, Object, int) when binding parameters
[
https://issues.apache.org/jira/browse/CALCITE-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1164:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.0)
> Use setObject(int, Object, int) when binding parameters
> ---
>
> Key: CALCITE-1164
> URL: https://issues.apache.org/jira/browse/CALCITE-1164
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Priority: Minor
> Fix For: avatica-1.21.0
>
>
> Trying to capture some discussion from a recent pull request:
> https://github.com/apache/calcite/pull/209#issuecomment-195025402
> In a few places (such as
> https://github.com/apache/calcite/blob/master/avatica/server/src/main/java/org/apache/calcite/avatica/jdbc/JdbcMeta.java#L795-L800),
> we perform:
> {code}
> TypedValue o = parameterValues.get(i);
> preparedStatement.setObject(i + 1, o.toJdbc(calendar));
> {code}
> Vladimir stated that this is ambiguous (stored procedures differing by
> argument list and differentiating between the actual type when the value is
> null) and would be remedied by passing along the desired type when setting
> the object.
> We may also have to invoke setNull explicitly? This is unclear to me.
> h5. Reasons why "explicit sql type" is important
> h6. Calling the proper function
> Consider database has two functions that differ in type of argument only.
> For instance {{compute(varchar)}}, {{compute(numeric)}}, and
> {{compute(user_defined_struct)}}
> Which one should be executed if calling with just
> {{preparedStatement.setObject(i, null)}}?
> There is not enough information for the database to choose between varchar
> and numeric function.
> h6. Performance
> Execution plan depends on the types of bind parameters. For instance, in
> PostgreSQL, you must tell all the datatypes of the bind variables right in
> {{PREPARE}} message.
> That basically means, if you flip between datatypes, you have to use
> different prepared statement IDs.
> If just {{String val = ...; ps.setObject(1, val)}} is used, then for non-null
> it can result in {{String}} execution plan, while for null it can flip to
> unknown.
> Same for batched statement execution. PostgreSQL just cannot handle datatype
> flips right in the middle of the batch. It is handled in the pgjdbc driver,
> so it cuts batch in several sub batches, so it becomes less efficient.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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:all-tabpanel ] Josh Elser updated CALCITE-1350: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > 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 >Priority: Major > Fix For: avatica-1.21.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 (v8.20.1#820001)
[jira] [Updated] (CALCITE-1286) Create self-contained test-harness for TCK
[ https://issues.apache.org/jira/browse/CALCITE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1286: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Create self-contained test-harness for TCK > -- > > Key: CALCITE-1286 > URL: https://issues.apache.org/jira/browse/CALCITE-1286 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.21.0 > > > Should make a Vagrant VM or a Docker image which is capable of automatically > running the Avatica TCK. > Ideally, running the TCK should be as simple as a single command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CALCITE-4931) Upgrade SLF4J binding to Log4j2 version 2.15.0
[ https://issues.apache.org/jira/browse/CALCITE-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-4931. - Resolution: Fixed > Upgrade SLF4J binding to Log4j2 version 2.15.0 > -- > > Key: CALCITE-4931 > URL: https://issues.apache.org/jira/browse/CALCITE-4931 > Project: Calcite > Issue Type: Task > Components: avatica >Affects Versions: avatica-1.19.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Log4j (binding) is used for testing purposes in various modules and for > production code (shaded) in standalone-server and tck modules. > The slf4j-log4j12 dependency (currently in use) relies on Log4j 1.x which has > reached [end of > life|https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces] > in 2015. > The goal of this issue is to replace slf4j-log4j12 with log4j-slf4j-impl > binding which uses Log4j2 and take the latest version. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CALCITE-4121) Avatica misplaces properties from URL while connecting
[
https://issues.apache.org/jira/browse/CALCITE-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-4121:
---
Assignee: Laksh Singla
> Avatica misplaces properties from URL while connecting
> --
>
> Key: CALCITE-4121
> URL: https://issues.apache.org/jira/browse/CALCITE-4121
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.17.0
>Reporter: Gian Merlino
>Assignee: Laksh Singla
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Avatica's driver goes through some effort to extract properties from the JDBC
> URL, but then loses them because it doesn't pass them to the
> {{OpenConnectionRequest}}:
> https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/java/org/apache/calcite/avatica/remote/Driver.java#L163-L181.
> I think the fix should be passing {{conn.info}} instead of {{info}}, because
> URL properties are added to {{conn.info}} in {{super.connect(url, info)}}.
> The fix looks simple enough — any suggestions on the best way to add tests
> for it?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4891) Avatica can't handle uuid fields saying 'Cannot handle class java.util.UUID as bytes'
[ https://issues.apache.org/jira/browse/CALCITE-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445325#comment-17445325 ] Josh Elser commented on CALCITE-4891: - Yeah, I am inclined to agree with you, Jamie. We coerce the UUID to bytes (or a utf-8 string) when sending that over the wire, so this error sounds like we messed up the wrapping/unwrapping across the wire. Do you have any aspirations to try to fix this? Seeing if we can write a simple unit test would be a good start – I would look at adding a test method to [RemoteMetaTest|https://github.com/apache/calcite-avatica/blob/master/server/src/test/java/org/apache/calcite/avatica/remote/RemoteMetaTest.java] > Avatica can't handle uuid fields saying 'Cannot handle class java.util.UUID > as bytes' > - > > Key: CALCITE-4891 > URL: https://issues.apache.org/jira/browse/CALCITE-4891 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.19.0 >Reporter: Jamie Taylor >Priority: Major > > When I try and fetch a value of type UUID through an avatica proxy I get an > error saying 'Cannot handle class java.util.UUID as bytes' > If I change the serilisation from json to protobuf I still get the exact same > error. > Other types that aren't supported such as blob give messages saying they > aren't supported, which makes this look like a bug. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CALCITE-4840) Avatica readme for source release should have better build instructions
[
https://issues.apache.org/jira/browse/CALCITE-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-4840.
-
Fix Version/s: avatica-1.20.0
Resolution: Fixed
Merged your PR, [https://github.com/apache/calcite-avatica/pull/159]
Thanks for the improvements, Jacques.
> Avatica readme for source release should have better build instructions
> ---
>
> Key: CALCITE-4840
> URL: https://issues.apache.org/jira/browse/CALCITE-4840
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
> Labels: newbie
> Fix For: avatica-1.20.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Right now, trying to figure out how you should build from the source release
> is too difficult (unless I missed something). To find the rather meagre
> instructions, you have to:
> # Open the README and see it says use README.md
> # Open README.md and follow the link to the avatica home
> # Click develop
> # Click avatica development guide link
> # Find and click "build from a source distribution"
> Good luck to someone to find that path :)
> When you get there, it states java 8 or later but trying to build with Java
> 17 fails. For reference, jvm I was using:
> {{% java --version}}
> {{openjdk 17 2021-09-14 LTS}}
> {{OpenJDK Runtime Environment Corretto-17.0.0.35.2 (build 17+35-LTS)}}
> {{OpenJDK 64-Bit Server VM Corretto-17.0.0.35.2 (build 17+35-LTS, mixed mode,
> sharing)}}
>
> Ideally the readme (or an install.md or a single click) should include:
> * Prerequisites to build (gradle 6.8.1 and Java 8?)
> * How to check signature
> * How to build & test
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-4152. - Fix Version/s: avatica-1.20.0 Resolution: Fixed > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435103#comment-17435103 ] Josh Elser commented on CALCITE-4152: - Officially moved the PR out of "draft" > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Assignee: Josh Elser >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4814) AvaticaConnection#isValid() doesn't correspond JDBC API
[
https://issues.apache.org/jira/browse/CALCITE-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422954#comment-17422954
]
Josh Elser commented on CALCITE-4814:
-
Whomever decides to pick this up and work on it, please be sure to give a clear
list as to what things we think are worthwhile and able to check (otherwise, I
fear that isValid() will turn into pandora's box with things that we _could_
check) :)
> AvaticaConnection#isValid() doesn't correspond JDBC API
> ---
>
> Key: CALCITE-4814
> URL: https://issues.apache.org/jira/browse/CALCITE-4814
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Rymar Maksym
>Priority: Major
>
> [AvaticaConnection|https://github.com/apache/calcite-avatica/blob/d52c2036224911d93fe3185f521768037e62a437/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L63]
> implements *Connection* interface of JDBC API, but it's *isValid()* method
> doesn't correspond [java documentation|#isValid(int)].
> Currently, *{{AvaticaConnection}}* only checks attribute *{{'closed'}}* via
> method *{{isClosed()}}* and do nothing more. With current implementation,
> *{{AvaticaConnection#isValid(int timeout)}}* totally correspond to
> *{{AvaticaConnection#isClosed()}}* what is actually incorrect, according to
> [java documentation|#isValid(int)].
> In it's turn, *{{AvaticaConnection#isClosed()}}* will return *{{'true'}}*,
> only when connection will be closed directly by client and it doesn't handle
> case, when server closes connection or server is not accessible due to
> network issues and etc.
>
> *{{AvaticaConnection#isValid}}* should check weather connection is valid. The
> driver may submit a query on the connection or use some other mechanism that
> positively verifies the connection is still valid when this method is called.
> Here is some examples of implementations in [MySql
> JDBC|https://github.com/mysql/mysql-connector-j/blob/18bbd5e68195d0da083cbd5bd0d05d76320df7cd/src/main/user-impl/java/com/mysql/cj/jdbc/ConnectionImpl.java#L2546]
> and [Postgres
> JDBC|https://github.com/pgjdbc/pgjdbc/blob/3a2bbd77969903f8a4ce721d45905c72bd1688d6/pgjdbc/src/main/java/org/postgresql/jdbc/PgConnection.java#L1407].
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1520) org.apache.calcite.avatica.AvaticaConnection: support isValid()
[
https://issues.apache.org/jira/browse/CALCITE-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422946#comment-17422946
]
Josh Elser commented on CALCITE-1520:
-
Thanks Rymar!
> org.apache.calcite.avatica.AvaticaConnection: support isValid()
> ---
>
> Key: CALCITE-1520
> URL: https://issues.apache.org/jira/browse/CALCITE-1520
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.10.0
> Environment: Windows
>Reporter: Ningli Fang
>Assignee: Kevin Risden
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently the calss org.apache.calcite.avatica.AvaticaConnection does not
> support isValid():
> {code}
> public boolean isValid(int timeout) throws SQLException {
> throw helper.unsupported();
> }
> {code}
> On JasperSoft server, we created a dataSource using Calcite jdbc driver. When
> use JasperSoft "test connection" feature, it failed with the exception:
> {noformat}
> java.sql.SQLFeatureNotSupportedException
> at org.apache.calcite.avatica.Helper.unsupported(Helper.java:68)
> at
> org.apache.calcite.avatica.AvaticaConnection.isValid(AvaticaConnection.java:373)
> at
> org.apache.commons.dbcp.DelegatingConnection.isValid(DelegatingConnection.java:626)
> at
> org.apache.commons.dbcp.DelegatingConnection.isValid(DelegatingConnection.java:626)
> at
> com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.JdbcDataSourceService.isConnectionValid(JdbcDataSourceService.java:102)
> at
> com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.JdbcDataSourceService.testConnection(JdbcDataSourceService.java:86)
> at
> com.jaspersoft.jasperserver.remote.connection.JdbcConnectionStrategy.createConnection(JdbcConnectionStrategy.java:76)
> at
> com.jaspersoft.jasperserver.remote.connection.JdbcConnectionStrategy.createConnection(JdbcConnectionStrategy.java:45)
> at
> com.jaspersoft.jasperserver.remote.connection.ConnectionsManager.createConnection(ConnectionsManager.java:72)
> at
> com.jaspersoft.jasperserver.jaxrs.connection.ConnectionsJaxrsService.createConnection(ConnectionsJaxrsService.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1483)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1414)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1363)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1353)
> at
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:414)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at
>
[jira] [Commented] (CALCITE-1520) org.apache.calcite.avatica.AvaticaConnection: support isValid()
[
https://issues.apache.org/jira/browse/CALCITE-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422750#comment-17422750
]
Josh Elser commented on CALCITE-1520:
-
[~mrymar] no, we won't open this issue because it was committed over 3 years
ago. If we were to do this and make a second code change, it will cause
confusion with users as to when the issue here was actually fixed.
Please file a new Jira issue with an explanation about what specifically is
wrong with the current implementation, ideally also with a patch to address
that problem. Thanks.
> org.apache.calcite.avatica.AvaticaConnection: support isValid()
> ---
>
> Key: CALCITE-1520
> URL: https://issues.apache.org/jira/browse/CALCITE-1520
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.10.0
> Environment: Windows
>Reporter: Ningli Fang
>Assignee: Kevin Risden
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently the calss org.apache.calcite.avatica.AvaticaConnection does not
> support isValid():
> {code}
> public boolean isValid(int timeout) throws SQLException {
> throw helper.unsupported();
> }
> {code}
> On JasperSoft server, we created a dataSource using Calcite jdbc driver. When
> use JasperSoft "test connection" feature, it failed with the exception:
> {noformat}
> java.sql.SQLFeatureNotSupportedException
> at org.apache.calcite.avatica.Helper.unsupported(Helper.java:68)
> at
> org.apache.calcite.avatica.AvaticaConnection.isValid(AvaticaConnection.java:373)
> at
> org.apache.commons.dbcp.DelegatingConnection.isValid(DelegatingConnection.java:626)
> at
> org.apache.commons.dbcp.DelegatingConnection.isValid(DelegatingConnection.java:626)
> at
> com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.JdbcDataSourceService.isConnectionValid(JdbcDataSourceService.java:102)
> at
> com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.JdbcDataSourceService.testConnection(JdbcDataSourceService.java:86)
> at
> com.jaspersoft.jasperserver.remote.connection.JdbcConnectionStrategy.createConnection(JdbcConnectionStrategy.java:76)
> at
> com.jaspersoft.jasperserver.remote.connection.JdbcConnectionStrategy.createConnection(JdbcConnectionStrategy.java:45)
> at
> com.jaspersoft.jasperserver.remote.connection.ConnectionsManager.createConnection(ConnectionsManager.java:72)
> at
> com.jaspersoft.jasperserver.jaxrs.connection.ConnectionsJaxrsService.createConnection(ConnectionsJaxrsService.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1483)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1414)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1363)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1353)
> at
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:414)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at
>
[jira] [Resolved] (CALCITE-4752) PreparedStatement#SetObject() fails for BigDecimal values
[
https://issues.apache.org/jira/browse/CALCITE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-4752.
-
Fix Version/s: avatica-1.19.0
Resolution: Fixed
Thanks for digging into this tricky piece of Avatica, Istvan.
> PreparedStatement#SetObject() fails for BigDecimal values
> -
>
> Key: CALCITE-4752
> URL: https://issues.apache.org/jira/browse/CALCITE-4752
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Affects Versions: 1.18.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Fix For: avatica-1.19.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> {code:java}
> preparedStatement.setObject(1, new BigDecimal.ONE)
> {code}
> results in an SqlException.
> Avatica should be able to deduce the type correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4752) PreparedStatement#SetObject() fails for BigDecimal values
[
https://issues.apache.org/jira/browse/CALCITE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-4752:
Affects Version/s: (was: 1.18.0)
avatica-1.18.0
> PreparedStatement#SetObject() fails for BigDecimal values
> -
>
> Key: CALCITE-4752
> URL: https://issues.apache.org/jira/browse/CALCITE-4752
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Affects Versions: avatica-1.18.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Fix For: avatica-1.19.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> {code:java}
> preparedStatement.setObject(1, new BigDecimal.ONE)
> {code}
> results in an SqlException.
> Avatica should be able to deduce the type correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4727) Possible incorrect RpcMetadata JSON reference
[ https://issues.apache.org/jira/browse/CALCITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17399447#comment-17399447 ] Josh Elser commented on CALCITE-4727: - bq. I thought that was maybe that was the culprit from the JSON serialization path. That's my only guess -- Jackson is trying to put something extra into the JSON type that wasn't expected by the original author (your's truly). I'll have to spin up a JSON-based example. It's been a while. > Possible incorrect RpcMetadata JSON reference > - > > Key: CALCITE-4727 > URL: https://issues.apache.org/jira/browse/CALCITE-4727 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: John Bodley >Priority: Trivial > > Per [CALCITE-4367|https://issues.apache.org/jira/browse/CALCITE-4367] the > RpMetadata JSON reference is missing the required `response` field. As > discussed in the issue and per > [here|https://github.com/apache/calcite-avatica/blob/89e0deb510311b85b8c8bacde6d2ff70c309930e/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2668-L2678], > though this isn't an actual response is does seem to expect a response type > signature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4727) Possible incorrect RpcMetadata JSON reference
[
https://issues.apache.org/jira/browse/CALCITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397723#comment-17397723
]
Josh Elser commented on CALCITE-4727:
-
{quote}That said [~elserj] per your comment the code snippet does say
{{RpcMetadataResponse}}, i.e., includes the term `response` for the JSON
messages, and per
[here|https://github.com/apache/calcite-avatica/blob/89e0deb510311b85b8c8bacde6d2ff70c309930e/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2668-L2678]
(as mentioned in the issue description) it seems like the RpcMetadata is
somewhat of an atypical
[miscellaneous|https://calcite.apache.org/avatica/docs/json_reference.html#miscellaneous]
type.
{quote}
The comment you're referring to here is simply saying that the class name is
"incorrectly" named as a "Response", not meant to imply that it requires a
"response" attribute.
Given your (excellent) explanation, it sounds to me like the JSON serialization
path is unexpectedly requiring the "response" attribute. In terms of the code
itself, Avatica is doing nothing with an "response" attribute on that message.
I know that we don't have a `response` attribute on the protobuf side.
Do you happen to have an encapsulated example I could run? (if not, I'll see if
I can gin something up).
> Possible incorrect RpcMetadata JSON reference
> -
>
> Key: CALCITE-4727
> URL: https://issues.apache.org/jira/browse/CALCITE-4727
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Priority: Trivial
>
> Per [CALCITE-4367|https://issues.apache.org/jira/browse/CALCITE-4367] the
> RpMetadata JSON reference is missing the required `response` field. As
> discussed in the issue and per
> [here|https://github.com/apache/calcite-avatica/blob/89e0deb510311b85b8c8bacde6d2ff70c309930e/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2668-L2678],
> though this isn't an actual response is does seem to expect a response type
> signature.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4727) Fix RpcMetadata JSON reference
[
https://issues.apache.org/jira/browse/CALCITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397600#comment-17397600
]
Josh Elser commented on CALCITE-4727:
-
{quote}the RpMetadata JSON reference is missing the required `response` field
{quote}
To echo Julian, I'm a little confused about what needs "fixing":
Proto:
{code}
// Generic metadata for the server to return with each response.
message RpcMetadata {
string server_address = 1; // The host:port of the server
}
{code}
JSON:
{code}
public RpcMetadataResponse(@JsonProperty("serverAddress") String
serverAddress) {
this.serverAddress = serverAddress;
this.serverAddressAsBytes =
UnsafeByteOperations.unsafeWrap(serverAddress.getBytes(UTF_8));
}
{code}
Both the protobuf and JSON protocols define RpcMetadata to contain just this
one attribute "serverAddress". As far as my poor memory goes, this field does
_not_ have a response attribute (in that it's not a typical response, like that
doc you link in the description).
> Fix RpcMetadata JSON reference
> ---
>
> Key: CALCITE-4727
> URL: https://issues.apache.org/jira/browse/CALCITE-4727
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Priority: Trivial
>
> Per [CALCITE-4367|https://issues.apache.org/jira/browse/CALCITE-4367] the
> RpMetadata JSON reference is missing the required `response` field. As
> discussed in the issue and per
> [here|https://github.com/apache/calcite-avatica/blob/89e0deb510311b85b8c8bacde6d2ff70c309930e/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2668-L2678],
> though this isn't an actual response is does seem to expect a response type
> signature.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4727) Fix RpcMetadata JSON reference
[ https://issues.apache.org/jira/browse/CALCITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397589#comment-17397589 ] Josh Elser commented on CALCITE-4727: - Thanks John! > Fix RpcMetadata JSON reference > --- > > Key: CALCITE-4727 > URL: https://issues.apache.org/jira/browse/CALCITE-4727 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: John Bodley >Priority: Trivial > > Per [CALCITE-4367|https://issues.apache.org/jira/browse/CALCITE-4367] the > RpMetadata JSON reference is missing the required `response` field. As > discussed in the issue and per > [here|https://github.com/apache/calcite-avatica/blob/89e0deb510311b85b8c8bacde6d2ff70c309930e/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2668-L2678], > though this isn't an actual response is does seem to expect a response type > signature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397499#comment-17397499
]
Josh Elser commented on CALCITE-4367:
-
[~john.bod...@gmail.com] thanks for coming back and keeping us honest on the
documentation. Could you open a new Jira issue for this extra correction? Happy
to get it fixed, but it helps us with tracking to get new issues filed (to
avoid difficult questions about when fixes were actually made).
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.18.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4676) Avatica client leaks TCP connections
[
https://issues.apache.org/jira/browse/CALCITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375825#comment-17375825
]
Josh Elser commented on CALCITE-4676:
-
Validated this with a naive test:
{code:java}
public static void main(String[] args) throws Exception {
for (int i = 0; i < 1000; i++) {
try (Connection conn =
DriverManager.getConnection("jdbc:avatica:remote:url=http://localhost:55000;serialization=protobuf;))
{
DatabaseMetaData metadata = conn.getMetaData();
ResultSet tables = metadata.getTables(null, null, null, null);
ArrayList tableList = new ArrayList<>();
while (tables.next()) {
String table = String.format("%s:%s", tables.getString(2),
tables.getString(3));
tableList.add(table);
}
tables.close();
System.out.println(tableList.size() + " tables seen");
}
}
System.out.println("Waiting...");
Thread.sleep(5 * 60 * 1000);
}
{code}
Used the hsqldb standalone server here, ala {{docker run --rm -P -it
avatica-hsqldb-server}} (sadly, this was broken during the Gradle migration and
never re-automated)
Without the fix, we can see lots of TCP connections for this one program:
{noformat}
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
79
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
83
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
87
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
242 {noformat}
With Istvan's fix, we can see:
{noformat}
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
1
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
1
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
1
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
1
% lsof -Pp $(jps -m | fgrep ConnectionLeak | awk '{print $1}') | fgrep -c TCP
1 {noformat}
> Avatica client leaks TCP connections
>
>
> Key: CALCITE-4676
> URL: https://issues.apache.org/jira/browse/CALCITE-4676
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.18.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
> The default Http client implmentation uses
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager to pool
> connections, and does not close the TCP connections explicitly when the JDBC
> connection is closed.
> However, the http client pools are created *per JDBC Connection*, so the
> pooling is effectively only used when concurrent statements are executed from
> the same Connection object.
> This also means that when the application opens and closes a lot of
> Connections, then every Connection leaves behind active (typically in
> CLOSE_WAIT) TCP connections, which are only cleaned up on GC.
> This wastes resources, and eventually breaks the application, as connection
> limits are reached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4676) Avatica client leaks TCP connections
[ https://issues.apache.org/jira/browse/CALCITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375783#comment-17375783 ] Josh Elser commented on CALCITE-4676: - Quite a find! bq. This also means that when the application opens and closes a lot of Connections, then every Connection leaves behind active (typically in CLOSE_WAIT) TCP connections, which are only cleaned up on GC. Ok, that's a pretty obvious gap in how we got here. Of course, we don't expect users to spin through making lots of Connections, but we should have also expected they would do this :) > Avatica client leaks TCP connections > > > Key: CALCITE-4676 > URL: https://issues.apache.org/jira/browse/CALCITE-4676 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.18.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > The default Http client implmentation uses > org.apache.http.impl.conn.PoolingHttpClientConnectionManager to pool > connections, and does not close the TCP connections explicitly when the JDBC > connection is closed. > However, the http client pools are created *per JDBC Connection*, so the > pooling is effectively only used when concurrent statements are executed from > the same Connection object. > This also means that when the application opens and closes a lot of > Connections, then every Connection leaves behind active (typically in > CLOSE_WAIT) TCP connections, which are only cleaned up on GC. > This wastes resources, and eventually breaks the application, as connection > limits are reached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4469) Accept standard JDBC user/password parameters
[ https://issues.apache.org/jira/browse/CALCITE-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270989#comment-17270989 ] Josh Elser commented on CALCITE-4469: - Heh, I was just thinking about this one this past week. The original purpose behind not using "user" and "password" was that we passed all configuration elements from Avatica down into the "real" JDBC driver inside of the server. The "real" jdbc driver inside the Avatica server may be doing its own authentication against the "real" database. This was the thinking where Avatica is acting as a "trusted proxy" in front of the database. However, there's another case to consider where Avatica should just pass along the user credentials to the "real" JDBC driver. I had tried to "handle" this way-back-when by just making Avatica have its own properties for authentication. However, I think, like Istvan says, the common case is either Avatica does the authentication itself _or_ Avatica passes the authentication directly to the database. In either case, we can use user and password. > Accept standard JDBC user/password parameters > - > > Key: CALCITE-4469 > URL: https://issues.apache.org/jira/browse/CALCITE-4469 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Priority: Major > > Having to use avatica_user and avatica_password in the URL is pain point for > new users. > Accept the standard user and password parameters as aliases. > This would also let users use the username/password fields in JDBC GUIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257140#comment-17257140 ] Josh Elser commented on CALCITE-4152: - Linking my draft PR. Needs cleanup, testing, doc updates, and performance validation. > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Assignee: Josh Elser >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[
https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257137#comment-17257137
]
Josh Elser commented on CALCITE-4152:
-
{code:java}
2020-12-31 23:21:35,831 [qtp2048434399-16] DEBUG - COMMIT for / on
HttpChannelOverHttp@584ac69e{s=HttpChannelState@5cea67c6{s=HANDLING
rs=COMPLETING os=COMMITTED is=READY awp=false se=false i=false
al=0},r=2,c=false/false,a=HANDLING,uri=//localhost:51706/,age=283}
200 null HTTP/1.1
Date: Fri, 01 Jan 2021 04:21:35 GMT
WWW-Authenticate: Negotiate
oYH1MIHyoAMKAQChCwYJKoZIhvcSAQICom4EbGBqBgkqhkiG9xIBAgICAG9bMFmgAwIBBaEDAgEPok0wS6ADAgERokQEQtpZnCRCej2MpfcD4oGTteO70BdUVSdd7Y4o/hqCP7ZB6YcXORaqxcEHjVjRLCZk1MLueoDiUO/YQh2CruAbVWMIBaNuBGxgagYJKoZIhvcSAQICAgBvWzBZoAMCAQWhAwIBD6JNMEugAwIBEaJEBELaWZwkQno9jKX3A+KBk7Xju9AXVFUnXe2OKP4agj+2QemHFzkWqsXBB41Y0SwmZNTC7nqA4lDv2EIdgq7gG1VjCAU=
Set-Cookie: JSESSIONID=node01mx0ketk9hfx2166mjptrygys60.node0; Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: application/octet-stream;charset=utf-8 {code}
With the new ConfigurableSpnegoAuthenticator/LoginService, Jetty will
automatically send back a JSESSIONID cookie and use that, as long as the
provided "duration" for cookie validity is not exceeded. Pretty slick.
We'll have to go through the other stuff that hadoop-auth does and make sure
that we don't need anything else (like {{Secure}} or {{HttpOnly}} options on
that cookie.).
> Avoid SPNEGO re-negotiation for each request
>
>
> Key: CALCITE-4152
> URL: https://issues.apache.org/jira/browse/CALCITE-4152
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Josh Elser
>Priority: Major
>
> When using SPNEGO authentication with Avatica, every HTTP request
> re-initiates the negotiation, doubling the number HTTP requests.
> Consider switching to cookies after the initial SPNEGO authentication
> succeeds.
> Jetty ticket that discusses the issue:
> [https://github.com/eclipse/jetty.project/issues/2868]
> Description of the Knox implementation
> [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257124#comment-17257124 ] Josh Elser commented on CALCITE-4152: - Hah, well, maybe back this whole train up. (I think Kevin suggested this elsewhere) The ConfigurableSpnegoAuthenticator already does exactly what we want here :) > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Assignee: Josh Elser >Priority: Major > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-4367.
-
Fix Version/s: avatica-1.18.0
Resolution: Fixed
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.18.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254396#comment-17254396 ] Josh Elser commented on CALCITE-4152: - I guess this approach is really just a JWT but not following that spec [https://jwt.io/introduction] Maybe step 5 should be "make it a JWT" > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Priority: Major > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[ https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-4152: --- Assignee: Josh Elser > Avoid SPNEGO re-negotiation for each request > > > Key: CALCITE-4152 > URL: https://issues.apache.org/jira/browse/CALCITE-4152 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Assignee: Josh Elser >Priority: Major > > When using SPNEGO authentication with Avatica, every HTTP request > re-initiates the negotiation, doubling the number HTTP requests. > Consider switching to cookies after the initial SPNEGO authentication > succeeds. > Jetty ticket that discusses the issue: > [https://github.com/eclipse/jetty.project/issues/2868] > Description of the Knox implementation > [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4152) Avoid SPNEGO re-negotiation for each request
[
https://issues.apache.org/jira/browse/CALCITE-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254375#comment-17254375
]
Josh Elser commented on CALCITE-4152:
-
Looking at this for fun, the general wag at what Hadoop is doing is this...
* After a successful SPNEGO auth'n, they send a SetCookie header back to the
client
* The cookie looks something like {{Set-Cookie:
hadoop.auth="u=guest=guest/c6401.ambari.apache@example.com=kerberos=1487947765114=fNpq9FYy2DA19Rah7586rgsAieI=";
Path=gateway/default; Domain=ambari.apache.org; Secure; HttpOnly}}
* The token data is "username", (kerberos) "principal", authentication type,
expiration time
* This token data is signed with HmacSHA256 and that's included as
"{{fNpq9FYy2DA19Rah7586rgsAieI="}}
* The signature is used when the token is passed back to the server to
validate that the token itself wasn't changed (e.g. user doesn't modify it and
say they're someone else)
* If the user doesn't provide the token (via the cookie), spnego authn happens
normally. When spnego authn succeeds, it sets a new cookie
* If the user provides the token (via the cookie) and the token is valid (the
signature matches), then user is marked as "authenticated" (as the user who is
specified in that auth token).
I think I can break this up into a couple of steps:
# Show that we can bypass spnego successfully with a cookie that just has
basic info. Will have to add indirection in AbstractAvaticaHandler to not pull
the user directly from the HttpServletRequest. Update the client, maybe (the
http client we use may automatically pass it along)?
# Make the plan cookie data into a protobuf or other serializable data
structure
# Add signing of the cookie data
# Add expiration of the auth cookie
> Avoid SPNEGO re-negotiation for each request
>
>
> Key: CALCITE-4152
> URL: https://issues.apache.org/jira/browse/CALCITE-4152
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Istvan Toth
>Priority: Major
>
> When using SPNEGO authentication with Avatica, every HTTP request
> re-initiates the negotiation, doubling the number HTTP requests.
> Consider switching to cookies after the initial SPNEGO authentication
> succeeds.
> Jetty ticket that discusses the issue:
> [https://github.com/eclipse/jetty.project/issues/2868]
> Description of the Knox implementation
> [https://cwiki.apache.org/confluence/display/KNOX/2017/02/24/Hadoop+Auth+%28SPNEGO+and+delegation+token+based+authentication%29+with+Apache+Knox]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254361#comment-17254361
]
Josh Elser commented on CALCITE-4367:
-
Pull request is up. If I don't get a review, I'll plan on committing this in a
few days.
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254357#comment-17254357
]
Josh Elser edited comment on CALCITE-4367 at 12/24/20, 1:47 AM:
{quote}
`RpcMetadata` is actually a response as opposed to a miscellaneous type per
[here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
and thus requires a {{response}} field. Note I'm not certain if this was
intentional, i.e., it being a response, however it it is it seems that it
should be renamed to {{RpcMetadataResponse}} for consistency.
{quote}
It's intentional that it isn't a response, as a "Response" was intended to be
top-level messages which might be sent back by the Avatica server. However,
it's not used by any requests, so it lives in responses.proto to avoid
polluting common.proto (for no reason). Hope this makes sense. I'll update the
comment to reflect this.
bq. The supplied ConnectionProperties contains an undocumented dirty field
(is_dirty for protobuf).
Good catch. Another funny one -- this shouldn't ever be sent over the wire.
It's just internal state used to avoid unnecessary RPCs (to sync the client's
properties with the properties in the Avatica server). I'll update the docs for
now, but we should circle back to avoid this getting serialized at all (for
json and proto)
The rest of these were spot-on. Thanks for the easy-to-incorporate feedback,
[~john.bod...@gmail.com]
was (Author: elserj):
{quote}
`RpcMetadata` is actually a response as opposed to a miscellaneous type per
[here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
and thus requires a {{response}} field. Note I'm not certain if this was
intentional, i.e., it being a response, however it it is it seems that it
should be renamed to {{RpcMetadataResponse}} for consistency.
It's intentional that it isn't a response, as a "Response" was intended to be
top-level messages which might be sent back by the Avatica server. However,
it's not used by any requests, so it lives in responses.proto to avoid
polluting common.proto (for no reason). Hope this makes sense. I'll update the
comment to reflect this.
bq. The supplied ConnectionProperties contains an undocumented dirty field
(is_dirty for protobuf).
Good catch. Another funny one -- this shouldn't ever be sent over the wire.
It's just internal state used to avoid unnecessary RPCs (to sync the client's
properties with the properties in the Avatica server). I'll update the docs for
now, but we should circle back to avoid this getting serialized at all (for
json and proto)
The rest of these were spot-on. Thanks for the easy-to-incorporate feedback,
[~john.bod...@gmail.com]
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254357#comment-17254357
]
Josh Elser commented on CALCITE-4367:
-
{quote}
`RpcMetadata` is actually a response as opposed to a miscellaneous type per
[here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
and thus requires a {{response}} field. Note I'm not certain if this was
intentional, i.e., it being a response, however it it is it seems that it
should be renamed to {{RpcMetadataResponse}} for consistency.
It's intentional that it isn't a response, as a "Response" was intended to be
top-level messages which might be sent back by the Avatica server. However,
it's not used by any requests, so it lives in responses.proto to avoid
polluting common.proto (for no reason). Hope this makes sense. I'll update the
comment to reflect this.
bq. The supplied ConnectionProperties contains an undocumented dirty field
(is_dirty for protobuf).
Good catch. Another funny one -- this shouldn't ever be sent over the wire.
It's just internal state used to avoid unnecessary RPCs (to sync the client's
properties with the properties in the Avatica server). I'll update the docs for
now, but we should circle back to avoid this getting serialized at all (for
json and proto)
The rest of these were spot-on. Thanks for the easy-to-incorporate feedback,
[~john.bod...@gmail.com]
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-4367:
---
Assignee: Josh Elser
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249864#comment-17249864
]
Josh Elser commented on CALCITE-4367:
-
Thanks for reporting, John. Will see if we can get the docs updated.
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4379) Meta.Frame created with java float values in rows hits a ClassCastException in toProto()
[
https://issues.apache.org/jira/browse/CALCITE-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-4379.
-
Fix Version/s: avatica-1.18.0
Resolution: Fixed
Pushed! Thanks for the contribution, Dmitri!
> Meta.Frame created with java float values in rows hits a ClassCastException
> in toProto()
>
>
> Key: CALCITE-4379
> URL: https://issues.apache.org/jira/browse/CALCITE-4379
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.17.0
>Reporter: Dmitri Bourlatchkov
>Assignee: Dmitri Bourlatchkov
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.18.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Use case:
> * Custom {{Meta}} implementation
> * {{Meta.Frame.create(offset, done, rows)}} is called with a row (a {{List}})
> containing a java {{Float}} value
> ** Note: the float value is fetched from Apache Cassandra, which has 32-bit
> float types (unlike SQL).
> ** Related [email
> discussion|https://mail-archives.apache.org/mod_mbox/calcite-dev/202011.mbox/%3CCAPSgeEREWLTNpBTpNBe4TY4hvwBWR9x-5BxAckKOTAE5QpoP9Q%40mail.gmail.com%3E]
>
> * The {{Frame}} is serialized by calling its {{.toProto()}} method
> * ClassCastException occurs
> Exception snippet:
> {noformat}
> java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Float
> at
> org.apache.calcite.avatica.remote.TypedValue.writeToProtoWithType(TypedValue.java:600)
> at org.apache.calcite.avatica.remote.TypedValue.toProto(TypedValue.java:805)
> at org.apache.calcite.avatica.Meta$Frame.serializeScalar(Meta.java:991)
> at org.apache.calcite.avatica.Meta$Frame.parseColumn(Meta.java:977)
> at org.apache.calcite.avatica.Meta$Frame.toProto(Meta.java:942)
> at
> org.apache.calcite.avatica.remote.Service$FetchResponse.serialize(Service.java:1468)
> [...snip...]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4379) Meta.Frame created with java float values in rows hits a ClassCastException in toProto()
[
https://issues.apache.org/jira/browse/CALCITE-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-4379:
---
Assignee: Dmitri Bourlatchkov
> Meta.Frame created with java float values in rows hits a ClassCastException
> in toProto()
>
>
> Key: CALCITE-4379
> URL: https://issues.apache.org/jira/browse/CALCITE-4379
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.17.0
>Reporter: Dmitri Bourlatchkov
>Assignee: Dmitri Bourlatchkov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Use case:
> * Custom {{Meta}} implementation
> * {{Meta.Frame.create(offset, done, rows)}} is called with a row (a {{List}})
> containing a java {{Float}} value
> ** Note: the float value is fetched from Apache Cassandra, which has 32-bit
> float types (unlike SQL).
> ** Related [email
> discussion|https://mail-archives.apache.org/mod_mbox/calcite-dev/202011.mbox/%3CCAPSgeEREWLTNpBTpNBe4TY4hvwBWR9x-5BxAckKOTAE5QpoP9Q%40mail.gmail.com%3E]
>
> * The {{Frame}} is serialized by calling its {{.toProto()}} method
> * ClassCastException occurs
> Exception snippet:
> {noformat}
> java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Float
> at
> org.apache.calcite.avatica.remote.TypedValue.writeToProtoWithType(TypedValue.java:600)
> at org.apache.calcite.avatica.remote.TypedValue.toProto(TypedValue.java:805)
> at org.apache.calcite.avatica.Meta$Frame.serializeScalar(Meta.java:991)
> at org.apache.calcite.avatica.Meta$Frame.parseColumn(Meta.java:977)
> at org.apache.calcite.avatica.Meta$Frame.toProto(Meta.java:942)
> at
> org.apache.calcite.avatica.remote.Service$FetchResponse.serialize(Service.java:1468)
> [...snip...]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-2795) New Avatica version doesn't support "list" type in query
[
https://issues.apache.org/jira/browse/CALCITE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-2795:
Priority: Critical (was: Blocker)
> New Avatica version doesn't support "list" type in query
>
>
> Key: CALCITE-2795
> URL: https://issues.apache.org/jira/browse/CALCITE-2795
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.14.0, 1.17.0, 1.18.0
>Reporter: Ayelet Morris
>Priority: Critical
>
> I created a simple POJO that has an id and a list and created a simple select
> query from it, I received the following exception, it seems that in previous
> versions (we used avatica 1.9 with calcite 1.11 before this upgrade) the list
> type was detected as "OTHER" type and the query worked, now it is marked as a
> Scalar but somehow finds its way to the "array" type of the types switch,
> then when trying to parse the column TYPE it fails (it doesn't even try to
> fetch the list itself)
> {noformat}
> java.lang.RuntimeException: exception while executing [SELECT * FROM
> TypeWithList]
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1458)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1426)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsUnordered(CalciteAssert.java:1464)
> at com.gigaspaces.jdbc.TypesTest.testSelectWithList(TypesTest.java:44)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)
> at
> org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0
> at org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:573)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1450)
> ... 33 more
> Caused by: java.sql.SQLException: Error while executing SQL "SELECT * FROM
> TypeWithList": org.apache.calcite.avatica.ColumnMetaData$ScalarType cannot be
> cast to org.apache.calcite.avatica.ColumnMetaData$ArrayType
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at
[jira] [Resolved] (CALCITE-4196) Avatica server responds with HTTP/401 prior to consuming all data written by client
[
https://issues.apache.org/jira/browse/CALCITE-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-4196.
-
Resolution: Fixed
Fixed in f9837420cfabf88874eeb2c0a5b9642ebe2c2461. Thanks to Kevin (and
Vladimir) for the reviews.
> Avatica server responds with HTTP/401 prior to consuming all data written by
> client
> ---
>
> Key: CALCITE-4196
> URL: https://issues.apache.org/jira/browse/CALCITE-4196
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.18.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> First off, big thanks to [~krisden] for pointing me to HIVE-22231 which was
> the similar problem on the Hive side.
> Symptoms: the client, when sending a large HTTP request to the Avatica server
> which is configured for SPNEGO authentication, e.g. an ExecuteBatchRequest
> with 100's to 1000's of rows to execute, will receive an HTTP/401 response as
> a part of the normal SPNEGO negotiation (described in
> [https://tools.ietf.org/html/rfc4559#section-5]). The client will observe an
> error similar to the following, indicate "Broken pipe".
> {noformat}
> 2020-08-24 17:21:54,512 DEBUG http.wire: http-outgoing-1 >> "[write] I/O
> error: Broken pipe (Write failed)"
> 2020-08-24 17:21:54,512 DEBUG conn.DefaultManagedHttpClientConnection:
> http-outgoing-1: Close connection
> 2020-08-24 17:21:54,512 DEBUG conn.DefaultManagedHttpClientConnection:
> http-outgoing-1: Shutdown connection
> 2020-08-24 17:21:54,512 DEBUG execchain.MainClientExec: Connection discarded
> 2020-08-24 17:21:54,512 DEBUG conn.PoolingHttpClientConnectionManager:
> Connection released: [id: 1][route: {}->http://avatica-server:8765][total
> kept alive: 0; route allocated: 0 of 25; total allocated: 0 of 100]
> 2020-08-24 17:21:54,512 INFO execchain.RetryExec: I/O exception
> (java.net.SocketException) caught when processing request to
> {}->http://avatica-server:8765: Broken pipe (Write failed)
> 2020-08-24 17:21:54,512 DEBUG execchain.RetryExec: Broken pipe (Write failed)
> java.net.SocketException: Broken pipe (Write failed)
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at
> java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
> at
> org.apache.calcite.avatica.org.apache.http.impl.conn.LoggingOutputStream.write(LoggingOutputStream.java:74)
> at
> org.apache.calcite.avatica.org.apache.http.impl.io.SessionOutputBufferImpl.streamWrite(SessionOutputBufferImpl.java:124)
> at
> org.apache.calcite.avatica.org.apache.http.impl.io.SessionOutputBufferImpl.write(SessionOutputBufferImpl.java:160)
> at
> org.apache.calcite.avatica.org.apache.http.impl.io.ContentLengthOutputStream.write(ContentLengthOutputStream.java:113)
> at
> org.apache.calcite.avatica.org.apache.http.entity.ByteArrayEntity.writeTo(ByteArrayEntity.java:112)
> at
> org.apache.calcite.avatica.org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity(DefaultBHttpClientConnection.java:156)
> at
> org.apache.calcite.avatica.org.apache.http.impl.conn.CPoolProxy.sendRequestEntity(CPoolProxy.java:152)
> at
> org.apache.calcite.avatica.org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:238)
> at
> org.apache.calcite.avatica.org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at
> org.apache.calcite.avatica.org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at
> org.apache.calcite.avatica.org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at
> org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientSpnegoImpl.send(AvaticaCommonsHttpClientSpnegoImpl.java:129)
> at
> org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient$1.run(DoAsAvaticaHttpClient.java:39)
> at
> org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient$1.run(DoAsAvaticaHttpClient.java:37)
> at java.security.AccessController.doPrivileged(Native Method)
> at
[jira] [Created] (CALCITE-4196) Avatica server responds with HTTP/401 prior to consuming all data written by client
Josh Elser created CALCITE-4196:
---
Summary: Avatica server responds with HTTP/401 prior to consuming
all data written by client
Key: CALCITE-4196
URL: https://issues.apache.org/jira/browse/CALCITE-4196
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.18.0
First off, big thanks to [~krisden] for pointing me to HIVE-22231 which was the
similar problem on the Hive side.
Symptoms: the client, when sending a large HTTP request to the Avatica server
which is configured for SPNEGO authentication, e.g. an ExecuteBatchRequest with
100's to 1000's of rows to execute, will receive an HTTP/401 response as a part
of the normal SPNEGO negotiation (described in
[https://tools.ietf.org/html/rfc4559#section-5]). The client will observe an
error similar to the following, indicate "Broken pipe".
{noformat}
2020-08-24 17:21:54,512 DEBUG http.wire: http-outgoing-1 >> "[write] I/O error:
Broken pipe (Write failed)"
2020-08-24 17:21:54,512 DEBUG conn.DefaultManagedHttpClientConnection:
http-outgoing-1: Close connection
2020-08-24 17:21:54,512 DEBUG conn.DefaultManagedHttpClientConnection:
http-outgoing-1: Shutdown connection
2020-08-24 17:21:54,512 DEBUG execchain.MainClientExec: Connection discarded
2020-08-24 17:21:54,512 DEBUG conn.PoolingHttpClientConnectionManager:
Connection released: [id: 1][route: {}->http://avatica-server:8765][total kept
alive: 0; route allocated: 0 of 25; total allocated: 0 of 100]
2020-08-24 17:21:54,512 INFO execchain.RetryExec: I/O exception
(java.net.SocketException) caught when processing request to
{}->http://avatica-server:8765: Broken pipe (Write failed)
2020-08-24 17:21:54,512 DEBUG execchain.RetryExec: Broken pipe (Write failed)
java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
at
org.apache.calcite.avatica.org.apache.http.impl.conn.LoggingOutputStream.write(LoggingOutputStream.java:74)
at
org.apache.calcite.avatica.org.apache.http.impl.io.SessionOutputBufferImpl.streamWrite(SessionOutputBufferImpl.java:124)
at
org.apache.calcite.avatica.org.apache.http.impl.io.SessionOutputBufferImpl.write(SessionOutputBufferImpl.java:160)
at
org.apache.calcite.avatica.org.apache.http.impl.io.ContentLengthOutputStream.write(ContentLengthOutputStream.java:113)
at
org.apache.calcite.avatica.org.apache.http.entity.ByteArrayEntity.writeTo(ByteArrayEntity.java:112)
at
org.apache.calcite.avatica.org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity(DefaultBHttpClientConnection.java:156)
at
org.apache.calcite.avatica.org.apache.http.impl.conn.CPoolProxy.sendRequestEntity(CPoolProxy.java:152)
at
org.apache.calcite.avatica.org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:238)
at
org.apache.calcite.avatica.org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.calcite.avatica.org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at
org.apache.calcite.avatica.org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at
org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientSpnegoImpl.send(AvaticaCommonsHttpClientSpnegoImpl.java:129)
at
org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient$1.run(DoAsAvaticaHttpClient.java:39)
at
org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient$1.run(DoAsAvaticaHttpClient.java:37)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at
org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient.send(DoAsAvaticaHttpClient.java:37)
at
org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:44)
at
org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:117)
at
org.apache.calcite.avatica.remote.RemoteMeta$20.call(RemoteMeta.java:430)
at
org.apache.calcite.avatica.remote.RemoteMeta$20.call(RemoteMeta.java:427)
at
[jira] [Updated] (CALCITE-4095) Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead of `SslContextFactory`
[ https://issues.apache.org/jira/browse/CALCITE-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-4095: Component/s: avatica > Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead > of `SslContextFactory` > -- > > Key: CALCITE-4095 > URL: https://issues.apache.org/jira/browse/CALCITE-4095 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Santiago Velasco >Assignee: Peter Somogyi >Priority: Major > Fix For: avatica-1.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > `SslContextFactory` is deprecated at Jetty 9.4. This issue replaces it with > `SslContextFactory.Server`. > - > [https://www.eclipse.org/jetty/javadoc/9.4.19.v20190610/org/eclipse/jetty/util/ssl/SslContextFactory.html] > - > [https://www.eclipse.org/jetty/javadoc/9.3.24.v20180605/org/eclipse/jetty/util/ssl/SslContextFactory.html] > > [https://github.com/apache/calcite-avatica/blob/e4711cb0ac8e72894c0c5b381892539673b348c2/server/src/main/java/org/apache/calcite/avatica/server/HttpServer.java#L816] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4095) Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead of `SslContextFactory`
[ https://issues.apache.org/jira/browse/CALCITE-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-4095: Fix Version/s: avatica-1.18.0 > Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead > of `SslContextFactory` > -- > > Key: CALCITE-4095 > URL: https://issues.apache.org/jira/browse/CALCITE-4095 > Project: Calcite > Issue Type: Task >Reporter: Santiago Velasco >Assignee: Peter Somogyi >Priority: Major > Fix For: avatica-1.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > `SslContextFactory` is deprecated at Jetty 9.4. This issue replaces it with > `SslContextFactory.Server`. > - > [https://www.eclipse.org/jetty/javadoc/9.4.19.v20190610/org/eclipse/jetty/util/ssl/SslContextFactory.html] > - > [https://www.eclipse.org/jetty/javadoc/9.3.24.v20180605/org/eclipse/jetty/util/ssl/SslContextFactory.html] > > [https://github.com/apache/calcite-avatica/blob/e4711cb0ac8e72894c0c5b381892539673b348c2/server/src/main/java/org/apache/calcite/avatica/server/HttpServer.java#L816] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4095) Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead of `SslContextFactory`
[ https://issues.apache.org/jira/browse/CALCITE-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-4095. - Resolution: Fixed > Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead > of `SslContextFactory` > -- > > Key: CALCITE-4095 > URL: https://issues.apache.org/jira/browse/CALCITE-4095 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Santiago Velasco >Assignee: Peter Somogyi >Priority: Major > Fix For: avatica-1.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > `SslContextFactory` is deprecated at Jetty 9.4. This issue replaces it with > `SslContextFactory.Server`. > - > [https://www.eclipse.org/jetty/javadoc/9.4.19.v20190610/org/eclipse/jetty/util/ssl/SslContextFactory.html] > - > [https://www.eclipse.org/jetty/javadoc/9.3.24.v20180605/org/eclipse/jetty/util/ssl/SslContextFactory.html] > > [https://github.com/apache/calcite-avatica/blob/e4711cb0ac8e72894c0c5b381892539673b348c2/server/src/main/java/org/apache/calcite/avatica/server/HttpServer.java#L816] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4095) Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead of `SslContextFactory`
[ https://issues.apache.org/jira/browse/CALCITE-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176505#comment-17176505 ] Josh Elser commented on CALCITE-4095: - Looks like Peter gave us a PR for this. Reassigning to him. Sorry if you were already working on this [~Aron.tao] > Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead > of `SslContextFactory` > -- > > Key: CALCITE-4095 > URL: https://issues.apache.org/jira/browse/CALCITE-4095 > Project: Calcite > Issue Type: Task >Reporter: Santiago Velasco >Assignee: Peter Somogyi >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > `SslContextFactory` is deprecated at Jetty 9.4. This issue replaces it with > `SslContextFactory.Server`. > - > [https://www.eclipse.org/jetty/javadoc/9.4.19.v20190610/org/eclipse/jetty/util/ssl/SslContextFactory.html] > - > [https://www.eclipse.org/jetty/javadoc/9.3.24.v20180605/org/eclipse/jetty/util/ssl/SslContextFactory.html] > > [https://github.com/apache/calcite-avatica/blob/e4711cb0ac8e72894c0c5b381892539673b348c2/server/src/main/java/org/apache/calcite/avatica/server/HttpServer.java#L816] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4095) Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead of `SslContextFactory`
[ https://issues.apache.org/jira/browse/CALCITE-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-4095: --- Assignee: Peter Somogyi (was: Jiatao Tao) > Update Jetty to 9.4.31.v20200723 and use `SslContextFactory.Server` instead > of `SslContextFactory` > -- > > Key: CALCITE-4095 > URL: https://issues.apache.org/jira/browse/CALCITE-4095 > Project: Calcite > Issue Type: Task >Reporter: Santiago Velasco >Assignee: Peter Somogyi >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > `SslContextFactory` is deprecated at Jetty 9.4. This issue replaces it with > `SslContextFactory.Server`. > - > [https://www.eclipse.org/jetty/javadoc/9.4.19.v20190610/org/eclipse/jetty/util/ssl/SslContextFactory.html] > - > [https://www.eclipse.org/jetty/javadoc/9.3.24.v20180605/org/eclipse/jetty/util/ssl/SslContextFactory.html] > > [https://github.com/apache/calcite-avatica/blob/e4711cb0ac8e72894c0c5b381892539673b348c2/server/src/main/java/org/apache/calcite/avatica/server/HttpServer.java#L816] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4138) Metadata operations via Avatica turn empty string args to null
[ https://issues.apache.org/jira/browse/CALCITE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-4138: Affects Version/s: (was: 1.17.0) avatica-1.17.0 > Metadata operations via Avatica turn empty string args to null > -- > > Key: CALCITE-4138 > URL: https://issues.apache.org/jira/browse/CALCITE-4138 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.17.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: pull-request-available > Fix For: avatica-1.18.0 > > Time Spent: 40m > Remaining Estimate: 0h > > DatabaseMetaData.getTables(), and some other functions have parameters > (catalog, schemaPattern), where null and empty String have different > semantics. > The corresponding protobuf fields in Avatica are Strings, and the Avatica > logic turns those args to null. > This makes it impossible to filter on actual empty string values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4138) Metadata operations via Avatica turn empty string args to null
[ https://issues.apache.org/jira/browse/CALCITE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-4138. - Fix Version/s: avatica-1.18.0 Resolution: Fixed Thanks for the nice fix, Istvan! I had to go back into the mental archives to remember how Calcite/Avatica does the website :). I modified your commit to calcite-avatica.git to include the markdown which generates the content (which is copied) into calcite-site.git/avatica. It was easy enough to adapt – just mentioning it for the next time! > Metadata operations via Avatica turn empty string args to null > -- > > Key: CALCITE-4138 > URL: https://issues.apache.org/jira/browse/CALCITE-4138 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.17.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: pull-request-available > Fix For: avatica-1.18.0 > > Time Spent: 40m > Remaining Estimate: 0h > > DatabaseMetaData.getTables(), and some other functions have parameters > (catalog, schemaPattern), where null and empty String have different > semantics. > The corresponding protobuf fields in Avatica are Strings, and the Avatica > logic turns those args to null. > This makes it impossible to filter on actual empty string values. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-2704) Multilingual decoded problem
[
https://issues.apache.org/jira/browse/CALCITE-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-2704:
---
Assignee: Feng Zhu
> Multilingual decoded problem
>
>
> Key: CALCITE-2704
> URL: https://issues.apache.org/jira/browse/CALCITE-2704
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.11.0, avatica-1.12.0, avatica-1.13.0
>Reporter: pufan
>Assignee: Feng Zhu
>Priority: Blocker
> Labels: pull-request-available
> Fix For: avatica-1.17.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> When we execute SQL with Chinese characters, we find that the server parses
> it in gibberish.
> After checking the code, we found that:
> org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 109：
> {code:java}
> //The readFully method USES utf-8 encoding internally.
> rawRequest = AvaticaUtils.readFully(inputStream, buffer);
> {code}
> But in the org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 116：
> {code:java}
> // Decoded using iso-8859-1 Cause Chinese garble.
> final String jsonRequest = new String(rawRequest.getBytes("ISO-8859-1"),
> "UTF-8");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-2704) Multilingual decoded problem
[
https://issues.apache.org/jira/browse/CALCITE-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-2704.
-
Resolution: Fixed
> Multilingual decoded problem
>
>
> Key: CALCITE-2704
> URL: https://issues.apache.org/jira/browse/CALCITE-2704
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.11.0, avatica-1.12.0, avatica-1.13.0
>Reporter: pufan
>Assignee: Feng Zhu
>Priority: Blocker
> Labels: pull-request-available
> Fix For: avatica-1.17.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> When we execute SQL with Chinese characters, we find that the server parses
> it in gibberish.
> After checking the code, we found that:
> org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 109：
> {code:java}
> //The readFully method USES utf-8 encoding internally.
> rawRequest = AvaticaUtils.readFully(inputStream, buffer);
> {code}
> But in the org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 116：
> {code:java}
> // Decoded using iso-8859-1 Cause Chinese garble.
> final String jsonRequest = new String(rawRequest.getBytes("ISO-8859-1"),
> "UTF-8");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-2704) Multilingual decoded problem
[
https://issues.apache.org/jira/browse/CALCITE-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-2704:
Priority: Major (was: Blocker)
> Multilingual decoded problem
>
>
> Key: CALCITE-2704
> URL: https://issues.apache.org/jira/browse/CALCITE-2704
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.11.0, avatica-1.12.0, avatica-1.13.0
>Reporter: pufan
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.17.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> When we execute SQL with Chinese characters, we find that the server parses
> it in gibberish.
> After checking the code, we found that:
> org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 109：
> {code:java}
> //The readFully method USES utf-8 encoding internally.
> rawRequest = AvaticaUtils.readFully(inputStream, buffer);
> {code}
> But in the org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 116：
> {code:java}
> // Decoded using iso-8859-1 Cause Chinese garble.
> final String jsonRequest = new String(rawRequest.getBytes("ISO-8859-1"),
> "UTF-8");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3506) ClassCastException in TypedValue.writetoProtoWithType when a boxed Float is used
[
https://issues.apache.org/jira/browse/CALCITE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975267#comment-16975267
]
Josh Elser commented on CALCITE-3506:
-
{quote}I don't longer have the exception, so it would be useful to know why the
cast from Float to long is needed. This doesn't mean this is the solution, but
I just wanted to understand if this was the real issue in my system.
{quote}
I wouldn't be surprised if it's unnecessary/wrong at this point, just wanted to
point out that I didn't think a real query would actually hit this code path
(which begs the question about the failure you saw).
If you can figure out a query which causes the original server-side issue, you
can always turn on TRACE (i think) for Avatica and see the data flowing over
the wire which should help understand what was actually serialized.
> ClassCastException in TypedValue.writetoProtoWithType when a boxed Float is
> used
>
>
> Key: CALCITE-3506
> URL: https://issues.apache.org/jira/browse/CALCITE-3506
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.12.0
>Reporter: Enrique Saurez
>Priority: Major
>
> am using Apache Calcite-Avatica version 1.12 (but the relevant code
> sections are not different from the master branch), and I am getting
> the following exception on the client side (but the actual error in on
> the server side):
> ||Exception||
> |org.apache.calcite.avatica.AvaticaSqlException: Error -1 (0) :
> Remote driver error: ClassCastException: java.lang.Long cannot be cast
> to java.lang.Float
> at org.apache.calcite.avatica.Helper.createException(Helper.java:54)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:557)
> at
> org.apache.calcite.avatica.AvaticaPreparedStatement.executeQuery(AvaticaPreparedStatement.java:137)
> at
> com.oltpbenchmark.benchmarks.tpcc.procedures.Payment.getCustomerByName(Payment.java:400)
> at
> com.oltpbenchmark.benchmarks.tpcc.procedures.Payment.run(Payment.java:221)
> at
> com.oltpbenchmark.benchmarks.tpcc.TPCCWorker.executeWork(TPCCWorker.java:74)
> at com.oltpbenchmark.api.Worker.doWork(Worker.java:386)
> at com.oltpbenchmark.api.Worker.run(Worker.java:296)
> at java.lang.Thread.run(Thread.java:748)
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Float
> at
> org.apache.calcite.avatica.remote.TypedValue.writeToProtoWithType(TypedValue.java:594)
> at
> org.apache.calcite.avatica.remote.TypedValue.toProto(TypedValue.java:799)
> at
> org.apache.calcite.avatica.Meta$Frame.serializeScalar(Meta.java:985)
> at org.apache.calcite.avatica.Meta$Frame.parseColumn(Meta.java:971)
> at org.apache.calcite.avatica.Meta$Frame.toProto(Meta.java:936)
> at
> org.apache.calcite.avatica.remote.Service$ResultSetResponse.serialize(Service.java:841)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteResponse.serialize(Service.java:1158)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteResponse.serialize(Service.java:1113)
> at
> org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> at
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
> 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|http://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:748)|
> From the code, it seems like when the function
[jira] [Commented] (CALCITE-3506) ClassCastException in TypedValue.writetoProtoWithType when a boxed Float is used
[
https://issues.apache.org/jira/browse/CALCITE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975243#comment-16975243
]
Josh Elser commented on CALCITE-3506:
-
I've spent some time messing around with this. TypedValue is a mess because
it's trying to reconcile all of these different representations of the same
data.
I can see the issue as you describe it, but the code snippet you suggest to add
to TypedValueTest doesn't really test what the code itself is actually doing.
It would be better to get a unit test reproducing the issue using a {{Frame}}
or a real query. For example, the following test which I added to
RemoteMetaTest.java passes without your change:
{code:java}
@Test public void testFloats() throws Exception {
final float floatValue = 3.14159f;
ConnectionSpec.getDatabaseLock().lock();
try (final Connection conn = DriverManager.getConnection(url);
final Statement stmt = conn.createStatement()) {
stmt.execute("DROP TABLE IF EXISTS testFloats");
stmt.execute("CREATE TABLE testFloats(id integer primary key, f float)");
try (final PreparedStatement pstmt = conn.prepareStatement("INSERT INTO
testFloats values(?,?)")) {
pstmt.setInt(1, 1);
pstmt.setFloat(2, floatValue);
assertEquals(1, pstmt.executeUpdate());
}
ResultSet results = stmt.executeQuery("SELECT * from testFloats");
assertNotNull(results);
assertTrue(results.next());
assertEquals(1, results.getInt(1));
float actual = results.getFloat(2);
assertTrue("Expected float values to be equal, but was " + actual,
floatValue == actual);
} finally {
ConnectionSpec.getDatabaseLock().unlock();
}
} {code}
> ClassCastException in TypedValue.writetoProtoWithType when a boxed Float is
> used
>
>
> Key: CALCITE-3506
> URL: https://issues.apache.org/jira/browse/CALCITE-3506
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.12.0
>Reporter: Enrique Saurez
>Priority: Major
>
> am using Apache Calcite-Avatica version 1.12 (but the relevant code
> sections are not different from the master branch), and I am getting
> the following exception on the client side (but the actual error in on
> the server side):
> ||Exception||
> |org.apache.calcite.avatica.AvaticaSqlException: Error -1 (0) :
> Remote driver error: ClassCastException: java.lang.Long cannot be cast
> to java.lang.Float
> at org.apache.calcite.avatica.Helper.createException(Helper.java:54)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:557)
> at
> org.apache.calcite.avatica.AvaticaPreparedStatement.executeQuery(AvaticaPreparedStatement.java:137)
> at
> com.oltpbenchmark.benchmarks.tpcc.procedures.Payment.getCustomerByName(Payment.java:400)
> at
> com.oltpbenchmark.benchmarks.tpcc.procedures.Payment.run(Payment.java:221)
> at
> com.oltpbenchmark.benchmarks.tpcc.TPCCWorker.executeWork(TPCCWorker.java:74)
> at com.oltpbenchmark.api.Worker.doWork(Worker.java:386)
> at com.oltpbenchmark.api.Worker.run(Worker.java:296)
> at java.lang.Thread.run(Thread.java:748)
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Float
> at
> org.apache.calcite.avatica.remote.TypedValue.writeToProtoWithType(TypedValue.java:594)
> at
> org.apache.calcite.avatica.remote.TypedValue.toProto(TypedValue.java:799)
> at
> org.apache.calcite.avatica.Meta$Frame.serializeScalar(Meta.java:985)
> at org.apache.calcite.avatica.Meta$Frame.parseColumn(Meta.java:971)
> at org.apache.calcite.avatica.Meta$Frame.toProto(Meta.java:936)
> at
> org.apache.calcite.avatica.remote.Service$ResultSetResponse.serialize(Service.java:841)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteResponse.serialize(Service.java:1158)
> at
> org.apache.calcite.avatica.remote.Service$ExecuteResponse.serialize(Service.java:1113)
> at
> org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
> at
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
> at
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
> at
>
[jira] [Commented] (CALCITE-3325) Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl Is Defined As Non Static Causing Memory Leak
[
https://issues.apache.org/jira/browse/CALCITE-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956310#comment-16956310
]
Josh Elser commented on CALCITE-3325:
-
{quote}Finally `UnsynchronizedBuffer.reset()` is invoked to make sure the
UnsynchronizedBuffer is ready for next invocation (which never happens because
on next invocation a new instance will be created :( ).
{quote}
I think this is the source of my confusion. Server-side, we generally have a
pool of threads which work incoming client requests. This is bounded to ensure
that the server won't be overrun if there's an influx of clients. If, within a
single thread, we're not getting the same instance of an UnsynchronizedBuffer,
then this code doesn't work right.
The same _should_ apply client side, but there's more ability for you to shoot
yourself in the foot (if you run a single operation on a thread and throw that
thread away). Because you're creating a new Connection every time, you're
throwing away any state we had for that thread, and re-creating everything. Why
aren't you keeping that Connection around?
The ThreadLocal is intended to be used as a "poor-man's" pool. I intended the
ThreadLocal to be a way that scales linearly with what the client is doing –
not that you, as the developer, have to be aware of some arcane configuration
property that you have to scale up as you vertically scale up your Avatica
client code (if that makes sense).
I appreciate you sharing the client code. I'll have to try to find some time
this week to make that functional (I don't have an avatica test harness ready
to go right now), and can look at that. If you have the cycles, I'd be curious
what your test shows if you changed it to do..
{code:java}
public void run() {
try (Connection con =
DriverManager.getConnection("jdbc:phoenix:thin:url=" + URL) {
while (true) {
try (PreparedStatement psmt =
con.prepareStatement("SELECT 1")) {
ResultSet rs = psmt.executeQuery();
rs.next();
Thread.sleep(100);
}
}
} catch (Exception e) { throw new RuntimeException(e); }
}
{code}
> Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl
> Is Defined As Non Static Causing Memory Leak
>
>
> Key: CALCITE-3325
> URL: https://issues.apache.org/jira/browse/CALCITE-3325
> Project: Calcite
> Issue Type: Bug
>Reporter: Mehdi Salarkia
>Priority: Major
> Attachments: Non-Static.snapshot, Non-static.png, Screen Shot
> 2019-09-05 at 5.05.20 PM.png, Screen Shot 2019-09-05 at 5.18.19 PM.png,
> Static.png, Static.snapshot
>
>
> As we were load testing our system on Apache Phoenix via the thin client
> which uses Avatica we ran into Garbage collection problems. After some
> investigation we could see there are a lot of unreferenced object due to this
> variable:
> {code:java}
> private final ThreadLocal threadLocalBuffer =
> new ThreadLocal() {
> @Override protected UnsynchronizedBuffer initialValue() {
> return new UnsynchronizedBuffer();
> }
> };
> {code}
> Which seems to be a reusable buffer for serializing/deserializing the data.
> From my understating there is a copy of this variable created per each
> instance of ProtobufTranslationImpl. However the proper use of ThreadLocal it
> seems to be one instance per thread and the current implementation seems to
> be missing the `static` keyword when defining the thread local variable:
> See [https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html]
> {code:java}
> ThreadLocal instances are typically private static fields in classes that
> wish to associate state with a thread (e.g., a user ID or Transaction ID).
> {code}
> See the attached snapshot from a memory dump we took.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3384) Support Kerberos-authentication using SPNEGO over HTTPS
[ https://issues.apache.org/jira/browse/CALCITE-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-3384. - Fix Version/s: avatica-1.16.0 Resolution: Fixed Thanks for the contribution, Istvan! Great to see someone poking at this. > Support Kerberos-authentication using SPNEGO over HTTPS > --- > > Key: CALCITE-3384 > URL: https://issues.apache.org/jira/browse/CALCITE-3384 > Project: Calcite > Issue Type: Improvement >Affects Versions: avatica-1.16.0 >Reporter: István Tóth >Assignee: István Tóth >Priority: Major > Labels: pull-request-available > Fix For: avatica-1.16.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Avatica supports both HTTPS connections, and kerberos authentication using > SPNEGO, but not both at same. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3384) Support Kerberos-authentication using SPNEGO over HTTPS
[ https://issues.apache.org/jira/browse/CALCITE-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-3384: --- Assignee: István Tóth > Support Kerberos-authentication using SPNEGO over HTTPS > --- > > Key: CALCITE-3384 > URL: https://issues.apache.org/jira/browse/CALCITE-3384 > Project: Calcite > Issue Type: Improvement >Affects Versions: avatica-1.16.0 >Reporter: István Tóth >Assignee: István Tóth >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Avatica supports both HTTPS connections, and kerberos authentication using > SPNEGO, but not both at same. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3325) Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl Is Defined As Non Static Causing Memory Leak
[
https://issues.apache.org/jira/browse/CALCITE-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926906#comment-16926906
]
Josh Elser commented on CALCITE-3325:
-
And again, it would be extremely helpful to be able to see exactly what you are
running. Please share your test harness.
> Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl
> Is Defined As Non Static Causing Memory Leak
>
>
> Key: CALCITE-3325
> URL: https://issues.apache.org/jira/browse/CALCITE-3325
> Project: Calcite
> Issue Type: Bug
>Reporter: Mehdi Salarkia
>Priority: Major
> Attachments: Non-Static.snapshot, Non-static.png, Screen Shot
> 2019-09-05 at 5.05.20 PM.png, Screen Shot 2019-09-05 at 5.18.19 PM.png,
> Static.png, Static.snapshot
>
>
> As we were load testing our system on Apache Phoenix via the thin client
> which uses Avatica we ran into Garbage collection problems. After some
> investigation we could see there are a lot of unreferenced object due to this
> variable:
> {code:java}
> private final ThreadLocal threadLocalBuffer =
> new ThreadLocal() {
> @Override protected UnsynchronizedBuffer initialValue() {
> return new UnsynchronizedBuffer();
> }
> };
> {code}
> Which seems to be a reusable buffer for serializing/deserializing the data.
> From my understating there is a copy of this variable created per each
> instance of ProtobufTranslationImpl. However the proper use of ThreadLocal it
> seems to be one instance per thread and the current implementation seems to
> be missing the `static` keyword when defining the thread local variable:
> See [https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html]
> {code:java}
> ThreadLocal instances are typically private static fields in classes that
> wish to associate state with a thread (e.g., a user ID or Transaction ID).
> {code}
> See the attached snapshot from a memory dump we took.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3325) Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl Is Defined As Non Static Causing Memory Leak
[
https://issues.apache.org/jira/browse/CALCITE-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926905#comment-16926905
]
Josh Elser commented on CALCITE-3325:
-
{quote}From my understanding objects stored in ThreadLocal are not removed
until a garbage collection happens due to insufficient memory, see in
java.lang.ThreadLocal.ThreadLocalMap:
{quote}
That rings a bell.
{quote}The client code runs on jetty which has a fixed thread pool for serving
the requests. We use a client side connection pool Avatica connections. The
connections could be recycled and used between threads but the connection pool
could also create/drop connections as necessary.
{quote}
When do you reuse a Connection/Thread vs. create a new one? Is the ThreadPool
you use a standard fixed java.util.concurrent.ThreadPool? (e.g. created by
{{Executors.newFixedThreadPool(int)}}?)
The thing I am looking from you is some clear indication that this is not a
symptom that your test framework is inducing. Right now, it's not clear to me
whether there is a problem in Avatica or you're just doing something in your
test harness that is exacerbating the GC.
Finally, let me be super clear: marking the buffer as static is _very wrong_.
As the name indicates, there is no synchronization of this buffer. If you are
reusing this buffer, it's going to result in data corruption issues.
> Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl
> Is Defined As Non Static Causing Memory Leak
>
>
> Key: CALCITE-3325
> URL: https://issues.apache.org/jira/browse/CALCITE-3325
> Project: Calcite
> Issue Type: Bug
>Reporter: Mehdi Salarkia
>Priority: Major
> Attachments: Non-Static.snapshot, Non-static.png, Screen Shot
> 2019-09-05 at 5.05.20 PM.png, Screen Shot 2019-09-05 at 5.18.19 PM.png,
> Static.png, Static.snapshot
>
>
> As we were load testing our system on Apache Phoenix via the thin client
> which uses Avatica we ran into Garbage collection problems. After some
> investigation we could see there are a lot of unreferenced object due to this
> variable:
> {code:java}
> private final ThreadLocal threadLocalBuffer =
> new ThreadLocal() {
> @Override protected UnsynchronizedBuffer initialValue() {
> return new UnsynchronizedBuffer();
> }
> };
> {code}
> Which seems to be a reusable buffer for serializing/deserializing the data.
> From my understating there is a copy of this variable created per each
> instance of ProtobufTranslationImpl. However the proper use of ThreadLocal it
> seems to be one instance per thread and the current implementation seems to
> be missing the `static` keyword when defining the thread local variable:
> See [https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html]
> {code:java}
> ThreadLocal instances are typically private static fields in classes that
> wish to associate state with a thread (e.g., a user ID or Transaction ID).
> {code}
> See the attached snapshot from a memory dump we took.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3325) Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl Is Defined As Non Static Causing Memory Leak
[
https://issues.apache.org/jira/browse/CALCITE-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924280#comment-16924280
]
Josh Elser commented on CALCITE-3325:
-
[~m2je], I don't believe your problem statement is correct.
First off, the ThreadLocal should not be static. ProtobufTranslationImpl is
already a threadsafe singleton. There's no benefit in making it the ThreadLocal
static because we should only ever have one instance of it per Connection.
The design here is that multiple threads in your application which are
interacting with the same Avatica Connection would be sharing this class. The
ThreadLocal ensures that each Thread which is using your Connection would also
keep using the same buffer to serialize/deserialize Protobuf messages
going/coming to/from the wire.
If you check out the ThreadLocal javadoc, they say this:
{quote}after a thread goes away, all of its copies of thread-local instances
are subject to garbage collection (unless other references to these copies
exist).
{quote}
There are also other instances of UnsynchronizedBuffer's which are used in the
client. Your screen shot is not clear enough to tell me anything. At best, it's
showing me ~256KB of heap usage (30 instances at 8KB) which is next to nothing.
If you're hoping for me to tell you what's going wrong, at a minimum, you
should be sharing the code you are using to test, verbatim instructions on how
to use that code, and the hprof file(s) you generated from your client
application.
Thanks.
> Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl
> Is Defined As Non Static Causing Memory Leak
>
>
> Key: CALCITE-3325
> URL: https://issues.apache.org/jira/browse/CALCITE-3325
> Project: Calcite
> Issue Type: Bug
>Reporter: Mehdi Salarkia
>Priority: Major
> Attachments: Screen Shot 2019-09-05 at 5.18.19 PM.png
>
>
> As we were load testing our system on Apache Phoenix via the thin client
> which uses Avatica we ran into Garbage collection problems. After some
> investigation we could see there are a lot of unreferenced object due to this
> variable:
> {code:java}
> private final ThreadLocal threadLocalBuffer =
> new ThreadLocal() {
> @Override protected UnsynchronizedBuffer initialValue() {
> return new UnsynchronizedBuffer();
> }
> };
> {code}
> Which seems to be a reusable buffer for serializing/deserializing the data.
> From my understating there is a copy of this variable created per each
> instance of ProtobufTranslationImpl. However the proper use of ThreadLocal it
> seems to be one instance per thread and the current implementation seems to
> be missing the `static` keyword when defining the thread local variable:
> See [https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html]
> {code:java}
> ThreadLocal instances are typically private static fields in classes that
> wish to associate state with a thread (e.g., a user ID or Transaction ID).
> {code}
> See the attached snapshot from a memory dump we took.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (CALCITE-2734) MongoDB adapter tutorial is out of date
[ https://issues.apache.org/jira/browse/CALCITE-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-2734. - Resolution: Fixed Resolving given Andrei's comments and lack of response from reporter. > MongoDB adapter tutorial is out of date > --- > > Key: CALCITE-2734 > URL: https://issues.apache.org/jira/browse/CALCITE-2734 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.17.0 > Environment: Host: Mac OS 10.14.1 > Calcite: Master >Reporter: TommyLike >Priority: Major > Labels: document > > Hey all, > I am trying to learn Calcite via MongoDB adapter, and I found there is a > related tutorial section in > [HOWTO|[https://calcite.apache.org/docs/howto.html#mongodb-adapter]|https://calcite.apache.org/docs/howto.html#mongodb-adapter],]. > But it seems to be a little out of date now, I found several issues at > least: > 1. model file: *mongo-zips-model.json* has been renamed into > *mongo-models.json.* > 2. data source file *zips.json* doesn't include all the data required in the > models.json file. > 3. the MongoDB adapter can not be directly used, because there is a log > related bug when execute command ``!connect > jdbc:calcite:model=mongodb/target/test-classes/mongo-model.json admin > admin``, related output: > ``` > SLF4J: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class > path, preempting StackOverflowError. > SLF4J: See also [http://www.slf4j.org/codes.html#log4jDelegationLoop] for > more details. > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > org.apache.log4j.Log4jLoggerFactory > ``` > > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CALCITE-2734) MongoDB adapter tutorial is out of date
[ https://issues.apache.org/jira/browse/CALCITE-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-2734: Component/s: (was: avatica) > MongoDB adapter tutorial is out of date > --- > > Key: CALCITE-2734 > URL: https://issues.apache.org/jira/browse/CALCITE-2734 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.17.0 > Environment: Host: Mac OS 10.14.1 > Calcite: Master >Reporter: TommyLike >Priority: Major > Labels: document > > Hey all, > I am trying to learn Calcite via MongoDB adapter, and I found there is a > related tutorial section in > [HOWTO|[https://calcite.apache.org/docs/howto.html#mongodb-adapter]|https://calcite.apache.org/docs/howto.html#mongodb-adapter],]. > But it seems to be a little out of date now, I found several issues at > least: > 1. model file: *mongo-zips-model.json* has been renamed into > *mongo-models.json.* > 2. data source file *zips.json* doesn't include all the data required in the > models.json file. > 3. the MongoDB adapter can not be directly used, because there is a log > related bug when execute command ``!connect > jdbc:calcite:model=mongodb/target/test-classes/mongo-model.json admin > admin``, related output: > ``` > SLF4J: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class > path, preempting StackOverflowError. > SLF4J: See also [http://www.slf4j.org/codes.html#log4jDelegationLoop] for > more details. > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > org.apache.log4j.Log4jLoggerFactory > ``` > > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CALCITE-2748) UPDATE doesn't work
[
https://issues.apache.org/jira/browse/CALCITE-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-2748:
Component/s: (was: avatica)
> UPDATE doesn't work
> ---
>
> Key: CALCITE-2748
> URL: https://issues.apache.org/jira/browse/CALCITE-2748
> Project: Calcite
> Issue Type: Bug
> Components: core, jdbc-adapter
>Affects Versions: 1.17.0
>Reporter: Alexander Shilov
>Priority: Major
>
> I tried to use UPDATE DML statements, but got exception:
> {code:java}
> java.lang.AssertionError: UPDATE
> at
> org.apache.calcite.adapter.enumerable.EnumerableTableModify.implement(EnumerableTableModify.java:137)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:100)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:92)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1238)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:332)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:211)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:200)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:91)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:175)
> ...{code}
> The reason is that EnumerableTableModify.implement doesn't support UPDATE.
> I've tried to implement it, but it's difficult with [Collection
> API|https://github.com/apache/calcite/blob/02752fe78f817ed317b8873d2f4c7b79bfe8b9b5/core/src/main/java/org/apache/calcite/schema/ModifiableTable.java#L40].
> There is no method in Collection, that can handle it, and if you use
> remove/add methods to simulate update, then updated rows count will be equals
> to zero.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-2795) New Avatica version doesn't support "list" type in query
[
https://issues.apache.org/jira/browse/CALCITE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874260#comment-16874260
]
Josh Elser commented on CALCITE-2795:
-
[~ayelet.mor...@gigaspaces.com], the "Unassigned" state means that no one is
working on this.
> New Avatica version doesn't support "list" type in query
>
>
> Key: CALCITE-2795
> URL: https://issues.apache.org/jira/browse/CALCITE-2795
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Ayelet Morris
>Priority: Blocker
>
> I created a simple POJO that has an id and a list and created a simple select
> query from it, I received the following exception, it seems that in previous
> versions (we used avatica 1.9 with calcite 1.11 before this upgrade) the list
> type was detected as "OTHER" type and the query worked, now it is marked as a
> Scalar but somehow finds its way to the "array" type of the types switch,
> then when trying to parse the column TYPE it fails (it doesn't even try to
> fetch the list itself)
> {noformat}
> java.lang.RuntimeException: exception while executing [SELECT * FROM
> TypeWithList]
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1458)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1426)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsUnordered(CalciteAssert.java:1464)
> at com.gigaspaces.jdbc.TypesTest.testSelectWithList(TypesTest.java:44)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)
> at
> org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0
> at org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:573)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1450)
> ... 33 more
> Caused by: java.sql.SQLException: Error while executing SQL "SELECT * FROM
> TypeWithList": org.apache.calcite.avatica.ColumnMetaData$ScalarType cannot be
> cast to org.apache.calcite.avatica.ColumnMetaData$ArrayType
> at
[jira] [Resolved] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-3090. - Resolution: Fixed Re-resolving after revert and application in [https://github.com/apache/calcite-avatica/commit/96507bfe737f2188c16dec9d16d5e8b502df231f] and [https://github.com/apache/calcite/commit/3fffb546154f4223a9b56feb30443bcbbee6ae72] > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847775#comment-16847775 ] Josh Elser commented on CALCITE-3090: - PR's 100 and 1234 are up which revert my original and just nuke the element entirely. > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847764#comment-16847764 ] Josh Elser commented on CALCITE-3090: - Scratch that. A follow-on is silly. I'll just revert and nuke this element. > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reopened CALCITE-3090: - > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3090) Update repository URL
[
https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847758#comment-16847758
]
Josh Elser commented on CALCITE-3090:
-
{quote}Did some more digging. Apache ASF POM [1] pulls from the Maven Super
POM[2]
{quote}
Thanks for digging, Kevin!
Let me spin out a second to just remove that.
> Update repository URL
> -
>
> Key: CALCITE-3090
> URL: https://issues.apache.org/jira/browse/CALCITE-3090
> Project: Calcite
> Issue Type: Task
> Components: avatica, build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0, avatica-1.16.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Use https for maven central.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-3090. - Resolution: Fixed Thanks for the quick reviews, Julian and Kevin! Fixed in Avatica and Calcite in [https://github.com/apache/calcite-avatica/commit/c96a9396e652e7bc1a71572b562e21ec3dc80c02] and [https://github.com/apache/calcite/commit/13102955bf0e1d6619593c5ef6fd0ef52a1be58d,] respectively. > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847747#comment-16847747 ] Josh Elser commented on CALCITE-3090: - I _think_ our configuration disallows us from pulling snapshots from central which, IMO, is a good thing. I think the default convention to add Central would allow snapshots, but I've not actually checked. > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847701#comment-16847701 ] Josh Elser commented on CALCITE-3090: - PR's up for both avatica and calcite. > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-3090: Component/s: build > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica, build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3090) Update repository URL
[ https://issues.apache.org/jira/browse/CALCITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-3090: Fix Version/s: 1.20.0 > Update repository URL > - > > Key: CALCITE-3090 > URL: https://issues.apache.org/jira/browse/CALCITE-3090 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0, avatica-1.16.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3090) Update repository URL
Josh Elser created CALCITE-3090: --- Summary: Update repository URL Key: CALCITE-3090 URL: https://issues.apache.org/jira/browse/CALCITE-3090 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.16.0 Use https for maven central. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2972) Upgrade jetty to 9.4.15.v20190215
[
https://issues.apache.org/jira/browse/CALCITE-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812427#comment-16812427
]
Josh Elser commented on CALCITE-2972:
-
{quote}We should make change to the docs/website with a compatibility change.
Do you want to do that as part of this change or separate JIRA?
{quote}
Either way. Doesn't really matter to me.
> Upgrade jetty to 9.4.15.v20190215
> -
>
> Key: CALCITE-2972
> URL: https://issues.apache.org/jira/browse/CALCITE-2972
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.14.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Avatica should be upgraded to the latest Jetty 9.4.15.v20190215
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2945) use equals in Boolean object compare
[ https://issues.apache.org/jira/browse/CALCITE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810353#comment-16810353 ] Josh Elser commented on CALCITE-2945: - Ok, thanks Francis! > use equals in Boolean object compare > > > Key: CALCITE-2945 > URL: https://issues.apache.org/jira/browse/CALCITE-2945 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: 1.16.0, 1.17.0, 1.18.0 >Reporter: leesf >Assignee: leesf >Priority: Minor > Labels: pull-request-available > Fix For: avatica-1.14.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > In ConnectionPropertiesImpl#merge funciton, we could use equals method in > Boolean object compare. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2945) use equals in Boolean object compare
[ https://issues.apache.org/jira/browse/CALCITE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-2945. - Resolution: Fixed Thanks for the fix, [~xleesf]. I've gone ahead and merged this. > use equals in Boolean object compare > > > Key: CALCITE-2945 > URL: https://issues.apache.org/jira/browse/CALCITE-2945 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: 1.16.0, 1.17.0, 1.18.0 >Reporter: leesf >Assignee: leesf >Priority: Minor > Labels: pull-request-available > Fix For: next > > Time Spent: 1.5h > Remaining Estimate: 0h > > In ConnectionPropertiesImpl#merge funciton, we could use equals method in > Boolean object compare. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2945) use equals in Boolean object compare
[
https://issues.apache.org/jira/browse/CALCITE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810348#comment-16810348
]
Josh Elser commented on CALCITE-2945:
-
[~francischuang], how have you been handling the fixVersion? Do you leave it as
{{next}} until you cut the next release?
> use equals in Boolean object compare
>
>
> Key: CALCITE-2945
> URL: https://issues.apache.org/jira/browse/CALCITE-2945
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.16.0, 1.17.0, 1.18.0
>Reporter: leesf
>Assignee: leesf
>Priority: Minor
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In ConnectionPropertiesImpl#merge funciton, we could use equals method in
> Boolean object compare.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2945) use equals in Boolean object compare
[ https://issues.apache.org/jira/browse/CALCITE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-2945: Fix Version/s: (was: next) avatica-1.14.0 > use equals in Boolean object compare > > > Key: CALCITE-2945 > URL: https://issues.apache.org/jira/browse/CALCITE-2945 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: 1.16.0, 1.17.0, 1.18.0 >Reporter: leesf >Assignee: leesf >Priority: Minor > Labels: pull-request-available > Fix For: avatica-1.14.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In ConnectionPropertiesImpl#merge funciton, we could use equals method in > Boolean object compare. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
