[jira] [Commented] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15959952#comment-15959952
]
Josh Elser commented on CALCITE-1353:
-
Hope you don't mind, [~francischuang], stealing this one from you :)
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (CALCITE-1353) first_frame_max_size in an ExecuteRequest should be an int32 in protobuf definitions.
[
https://issues.apache.org/jira/browse/CALCITE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1353:
---
Assignee: Josh Elser (was: Francis Chuang)
> first_frame_max_size in an ExecuteRequest should be an int32 in protobuf
> definitions.
> -
>
> Key: CALCITE-1353
> URL: https://issues.apache.org/jira/browse/CALCITE-1353
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.10.0
>
>
> In the protobuf definition for {{ExecuteRequest}}, the
> {{first_frame_max_size}} parameter is typed as an {{uint64}}. See
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L130.
> For consistency, it should be an {{int32}}.
> Similar parameters relating to the frame size are all typed as {{int32}}.
> For a {{PrepareAndExecuteRequest}}, {{first_frame_max_size}} is a{{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L78
> For a {{FetchRequest}}, {{frame_max_size}} is a {{int32}}:
> https://github.com/apache/calcite/blob/master/avatica/core/src/main/protobuf/requests.proto#L96
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CALCITE-1744) Cleanup avatica project pom
[ https://issues.apache.org/jira/browse/CALCITE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1744. - Resolution: Fixed Eclipse is happy locally and we had a nice reduction in pom.xml sizes Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=d961f4d6019f778ad1b886dc344bbc1dd66fc17f > Cleanup avatica project pom > --- > > Key: CALCITE-1744 > URL: https://issues.apache.org/jira/browse/CALCITE-1744 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: avatica-1.10.0 > > > I'm noticing that, somehow, avatica has inherited a number of > plugins/dependencies it doesn't actually need (e.g. freemarker). > Make a pass through the poms to remove unnecessary things after the split and > try to get Eclipse happy on a fresh import. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1561) Intermittent test failures
[
https://issues.apache.org/jira/browse/CALCITE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15969480#comment-15969480
]
Josh Elser commented on CALCITE-1561:
-
Thanks, Eli! I had taken a look at the output but it wasn't obvious to me as to
why they were failing. I appreciate you picking these up to review!
> Intermittent test failures
> --
>
> Key: CALCITE-1561
> URL: https://issues.apache.org/jira/browse/CALCITE-1561
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> A few tests are currently failing intermittently.
> 1. UdfTest
> {noformat}
> UdfTest.testUserDefinedFunction:162
> Expected: is <9>
> but: was <10>
> {noformat}
> 2. StreamTest.testInfiniteStreamsDoNotBufferInMemory
> {noformat}
> FAILURE! - in org.apache.calcite.test.StreamTest
> testInfiniteStreamsDoNotBufferInMemory(org.apache.calcite.test.StreamTest)
> Time elapsed: 0.218 sec <<< ERROR!
> java.lang.RuntimeException: exception while executing [select stream * from
> orders]
> at
> org.apache.calcite.test.StreamTest.testInfiniteStreamsDoNotBufferInMemory(StreamTest.java:237)
> Caused by: java.util.NoSuchElementException
> at
> org.apache.calcite.test.StreamTest.testInfiniteStreamsDoNotBufferInMemory(StreamTest.java:237)
> {noformat}
> I don't consider any of them serious -- they are test issues, not product
> correctness issues -- but they are inconvenient because false negatives waste
> developer time.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1050) Avatica can't serialize java.sql.Array
[ https://issues.apache.org/jira/browse/CALCITE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973884#comment-15973884 ] Josh Elser commented on CALCITE-1050: - Yeah, agreed on the Array interface portion, James. I think I saw the code I was stepping through was in some PData type classes, but I'd have to pull it up again. My hunch here is that I've fallen into a typo in the docs, but maybe there's a reason this was documented as such :). Granted, even if this was the case, we'd still be getting the ClassCastExceptions (trying to cast a Avatica's ArrayImpl into PhoenixArray, but that's for another day). > Avatica can't serialize java.sql.Array > -- > > Key: CALCITE-1050 > URL: https://issues.apache.org/jira/browse/CALCITE-1050 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: 1.5.0 >Reporter: Lukas Lalinsky >Assignee: Josh Elser > Fix For: avatica-1.10.0 > > > As far as I can see, there is no way to serialize arrays in the Avatica RPC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CALCITE-1756) Implicit and explicit "null" not handled correctly with protobuf
[
https://issues.apache.org/jira/browse/CALCITE-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1756.
-
Resolution: Fixed
Resolved in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=557f15cc74ade0e4bd509838b263f85a7b3d0215
> Implicit and explicit "null" not handled correctly with protobuf
>
>
> Key: CALCITE-1756
> URL: https://issues.apache.org/jira/browse/CALCITE-1756
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.10.0
>
>
> In finishing up the implementation for CALCITE-1050, I found that a unit test
> has been passing unintentionally.
> When the user does not provide a value for an unbound parameter on a
> Statement, the code is supposed to fail server-side. However, this was
> actually failing client side for the protobuf path, due to Protobuf's
> avoidance of "null" values.
> Need to make sure that we differentiate between explicitly null values
> ({{statement.setObject(1, null)}}) and implicitly null values (no value was
> set).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CALCITE-1050) Avatica can't serialize java.sql.Array
[ https://issues.apache.org/jira/browse/CALCITE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1050. - Resolution: Fixed Thanks for all of the reviews/feedback, folks. Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=dd65a2b18b8c35cfccf1c47b6be87ea7db3ad658 > Avatica can't serialize java.sql.Array > -- > > Key: CALCITE-1050 > URL: https://issues.apache.org/jira/browse/CALCITE-1050 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: 1.5.0 >Reporter: Lukas Lalinsky >Assignee: Josh Elser > Fix For: avatica-1.10.0 > > > As far as I can see, there is no way to serialize arrays in the Avatica RPC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1915) Workaround Jetty SpnegoAuthenticator bug where no challenge is sent
[ https://issues.apache.org/jira/browse/CALCITE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110172#comment-16110172 ] Josh Elser commented on CALCITE-1915: - AIUI, this will land in the next Jetty-9.4 release. As such, until we change from Jetty-9.2 to 9.4, we'll have to have a workaround. The change is easy, but writing a test will take a little bit of time. I'll try to do this tmrw so it doesn't wane. > Workaround Jetty SpnegoAuthenticator bug where no challenge is sent > --- > > Key: CALCITE-1915 > URL: https://issues.apache.org/jira/browse/CALCITE-1915 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.11.0 > > > I stumbled across what I think is a bug in Jetty per the RFC-7616. The RFC > reads (to me) as the following: > When a client sends an authorization header that is not capable of being used > to authenticate via SPNEGO, the server should send back the > WWW-Authentication: Negotiate HTTP header with a status code of HTTP/401. > Jetty will only send this challenge+401 when *no* Authorization header is > provided. > In the case where Avatica is sitting behind a reverse-proxy, the proxy _may_ > choose to pass along another authorization header. Jetty (and Avatica) should > still respond to say "You need to authenticate over SPNEGO". > At least Jetty dev seems to agree with my assessment: > https://github.com/eclipse/jetty.project/issues/1698. We can easily work > around this in Avatica while we wait to get a Jetty release which has this > fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1915) Workaround Jetty SpnegoAuthenticator bug where no challenge is sent
Josh Elser created CALCITE-1915: --- Summary: Workaround Jetty SpnegoAuthenticator bug where no challenge is sent Key: CALCITE-1915 URL: https://issues.apache.org/jira/browse/CALCITE-1915 Project: Calcite Issue Type: Bug Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.11.0 I stumbled across what I think is a bug in Jetty per the RFC-7616. The RFC reads (to me) as the following: When a client sends an authorization header that is not capable of being used to authenticate via SPNEGO, the server should send back the WWW-Authentication: Negotiate HTTP header with a status code of HTTP/401. Jetty will only send this challenge+401 when *no* Authorization header is provided. In the case where Avatica is sitting behind a reverse-proxy, the proxy _may_ choose to pass along another authorization header. Jetty (and Avatica) should still respond to say "You need to authenticate over SPNEGO". At least Jetty dev seems to agree with my assessment: https://github.com/eclipse/jetty.project/issues/1698. We can easily work around this in Avatica while we wait to get a Jetty release which has this fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1922) Work around Jetty issue where Kerberos v5 OID is disallowed for SPNEGO authentication
Josh Elser created CALCITE-1922:
---
Summary: Work around Jetty issue where Kerberos v5 OID is
disallowed for SPNEGO authentication
Key: CALCITE-1922
URL: https://issues.apache.org/jira/browse/CALCITE-1922
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.11.0
This appears to be another Jetty bug around SPNEGO. Huge thank you to
[~kishore1729] for his help in debugging this issue. I could not have done it
without his help.
Deploying the Avatica server behind a reverse-proxy, we observed that the
server would deny the authentication requests from the client (whereas the
client talking directly to Avatica was successful). Pardon the Phoenix classes
instead of Avatica itself:
{noformat}
2017-08-03 19:09:29,440 WARN
org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService:
GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept
at
sun.security.jgss.GSSCredentialImpl.getElement(GSSCredentialImpl.java:600)
at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:317)
at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService.login(SpnegoLoginService.java:137)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:61)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.SpnegoAuthenticator.validateRequest(SpnegoAuthenticator.java:99)
at
org.apache.calcite.avatica.server.AvaticaSpnegoAuthenticator.validateRequest(AvaticaSpnegoAuthenticator.java:43)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:512)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.Server.handle(Server.java:499)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.apache.phoenix.shaded.org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
2017-08-03 19:09:29,441 DEBUG
org.apache.calcite.avatica.server.AvaticaJsonHandler: HTTP request from
10.0.0.63 is unauthenticated and authentication is required
{noformat}
Investigating this further, we found that Jetty's SpnegoLoginService was
explicitly only allowing an OID of 1.3.6.1.5.5.2 instead of allowing both
1.3.6.1.5.5.2 for SPNEGO and 1.2.840.113554.1.2.2 for Kerberos v5 (e.g. See
Presto's SpnegoFilter class:
https://github.com/prestodb/presto/blob/master/presto-main/src/main/java/com/facebook/presto/server/security/SpnegoFilter.java#L113-L114).
Best as I can tell, this is a limitation in Jetty to only allow the SPNEGO OID
and not both.
We were able to observe that this wasn't a problem with the "stock" Avatica
client that uses commons-httpclient because it sends both the kerberos v5 OID
and spnego OID (each with data, of course).
We need to add a workaround to Avatica while we get this upstream in Jetty.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1923) Investigate HTTP connection caching with SPNEGO auth
Josh Elser created CALCITE-1923:
---
Summary: Investigate HTTP connection caching with SPNEGO auth
Key: CALCITE-1923
URL: https://issues.apache.org/jira/browse/CALCITE-1923
Project: Calcite
Issue Type: Task
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Minor
In the course of CALCITE-1922, I was doing a bunch of inspect of the raw HTTP
requests using tcpdump
{noformat}
tcpdump -vv port 8765 and '(tcp-syn|tcp-ack)!=0' -A
{noformat}
The strange thing is that for every request, the client appeared to be going
through the handshake each time (making two requests for every one). This seems
really bad to me and I'd expect to only see one made for the 2nd-nth request.
Maybe we're doing something wrong with authentication caching.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1922) Work around Jetty issue where Kerberos v5 OID is disallowed for SPNEGO authentication
[
https://issues.apache.org/jira/browse/CALCITE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1922.
-
Resolution: Fixed
Fixed in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=d19740921dfab7fae981bc10c07fd1bcbd9de56b
> Work around Jetty issue where Kerberos v5 OID is disallowed for SPNEGO
> authentication
> -
>
> Key: CALCITE-1922
> URL: https://issues.apache.org/jira/browse/CALCITE-1922
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
>
> This appears to be another Jetty bug around SPNEGO. Huge thank you to
> [~kishore1729] for his help in debugging this issue. I could not have done it
> without his help.
> Deploying the Avatica server behind a reverse-proxy, we observed that the
> server would deny the authentication requests from the client (whereas the
> client talking directly to Avatica was successful). Pardon the Phoenix
> classes instead of Avatica itself:
> {noformat}
> 2017-08-03 19:09:29,440 WARN
> org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService:
> GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept
> at
> sun.security.jgss.GSSCredentialImpl.getElement(GSSCredentialImpl.java:600)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:317)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService.login(SpnegoLoginService.java:137)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:61)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.SpnegoAuthenticator.validateRequest(SpnegoAuthenticator.java:99)
> at
> org.apache.calcite.avatica.server.AvaticaSpnegoAuthenticator.validateRequest(AvaticaSpnegoAuthenticator.java:43)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:512)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.Server.handle(Server.java:499)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:748)
> 2017-08-03 19:09:29,441 DEBUG
> org.apache.calcite.avatica.server.AvaticaJsonHandler: HTTP request from
> 10.0.0.63 is unauthenticated and authentication is required
> {noformat}
> Investigating this further, we found that Jetty's SpnegoLoginService was
> explicitly only allowing an OID of 1.3.6.1.5.5.2 instead of allowing both
> 1.3.6.1.5.5.2 for SPNEGO and 1.2.840.113554.1.2.2 for Kerberos v5 (e.g. See
> Presto's SpnegoFilter class:
> https://github.com/prestodb/presto/blob/master/presto-main/src/main/java/com/facebook/presto/server/security/SpnegoFilter.java#L113-L114).
> Best as I can tell, this is a limitation in Jetty to only allow the SPNEGO
> OID and not both.
> We were able to observe that this wasn't a problem with the "stock" Avatica
> client that uses commons-httpclient because it sends both the kerberos v5 OID
> and spnego OID (each with data, of course).
> We need to add a workaround to Avatica while we get this upstream in Jetty.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1915) Workaround Jetty SpnegoAuthenticator bug where no challenge is sent
[ https://issues.apache.org/jira/browse/CALCITE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1915. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=bc0e8bf5b287ca27b35df30b1568c8c389f70b4f > Workaround Jetty SpnegoAuthenticator bug where no challenge is sent > --- > > Key: CALCITE-1915 > URL: https://issues.apache.org/jira/browse/CALCITE-1915 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.11.0 > > > I stumbled across what I think is a bug in Jetty per the RFC-7616. The RFC > reads (to me) as the following: > When a client sends an authorization header that is not capable of being used > to authenticate via SPNEGO, the server should send back the > WWW-Authentication: Negotiate HTTP header with a status code of HTTP/401. > Jetty will only send this challenge+401 when *no* Authorization header is > provided. > In the case where Avatica is sitting behind a reverse-proxy, the proxy _may_ > choose to pass along another authorization header. Jetty (and Avatica) should > still respond to say "You need to authenticate over SPNEGO". > At least Jetty dev seems to agree with my assessment: > https://github.com/eclipse/jetty.project/issues/1698. We can easily work > around this in Avatica while we wait to get a Jetty release which has this > fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123753#comment-16123753 ] Josh Elser commented on CALCITE-1938: - bq. Josh Elser might be better able to set up CI. He did it for Calcite and Avatica. Would you mind taking this on, Josh? Yup! Not a problem. Will try to do it this weekend. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125183#comment-16125183 ] Josh Elser commented on CALCITE-1938: - bq. I'd definitely keep the tests running against Phoenix at the very least since the driver advertises Phoenix support Support for Phoenix's use of Avatica should be secondary to making sure that it works against Avatica "proper". bq. It's possible to duplicate the tests and run them twice, once on Phoenix and once on avatica + hsqldb, but I am wondering if the payoff is worth it (tests would probably take twice as long to run). Couldn't something be done to figure out the flavor of database and what it supports? I think we have driver information already sent back from the server. Maybe it's as simple as returning that back? Syntax shouldn't matter for the driver itself, just the sql provided, no? Anyways, I don't think it's a good use of our time to try to deploy a full hbase installation on the ASF infra. It tends to be over-taxed already -- a minimal testing environment is the best plan of action. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125103#comment-16125103
]
Josh Elser commented on CALCITE-1938:
-
{noformat}
$ mkdir -p ~/go/src/github.com/apache
$ git clone https://git-wip-us.apache.org/repos/asf/calcite-avatica-go.git
$ cd calcite-avatica-go
$ dep ensure
$ go test $(go list ./... | grep -v vendor)
{noformat}
The {{go test}} command just seems to hang and not do anything. I can't seem to
find any sort of option for more verbosity either. Thoughts, [~francischuang]?
> First Apache release for Avatica Go
> ---
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avacica Go, so expect more
> diligence / issues than usual.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125127#comment-16125127 ] Josh Elser commented on CALCITE-1938: - bq. The tests are integration tests, so you'd need to have an instance of Phoenix and PQS available Ok.. the README needs to be updated then. It's a bit misleading at this point. Do you have any "traditional" unit tests on the horizon? How much work do you think it would be to use https://hub.docker.com/r/apache/calcite-avatica/ instead (avatica + hsqldb)? Reducing the scope of what is required to run tests would be great. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1948) Publish avatica-hypersql, avatica-mysql and avatica-postgres to docker hub
[ https://issues.apache.org/jira/browse/CALCITE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16129762#comment-16129762 ] Josh Elser commented on CALCITE-1948: - [~francischuang], these were not published intentionally. As I understand it, these would constitute a "release". I know that ASF policy would preclude us from publishing a MySQL image -- that's why it's only provided as an example. HyperSQL wouldn't be a problem, but I'm not sure if the postgres license is accepted. This requires some research to proceed. > Publish avatica-hypersql, avatica-mysql and avatica-postgres to docker hub > -- > > Key: CALCITE-1948 > URL: https://issues.apache.org/jira/browse/CALCITE-1948 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Assignee: Josh Elser > > I am currently making a port of the tests in calcite-avatica-go to test > against the calcite-avatica image in docker hub. > Unfortunately, the calcite-avatica image only includes the avatica-server, > which makes it difficult to stand up a test environment. > It would be nice if the docker images for HyperSQL, MySQL and Postgres can be > published as well. > This can be achieved by configuring docker hub's automatic build to look in > the appropriate subfolders for the dockerfile and push tags with the > appropriate backing db, for example 1.10.0-hypersql, 1.10.0-mysql etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130350#comment-16130350 ] Josh Elser commented on CALCITE-1938: - bq. This will allow merging PRs on Github IMO, I don't see the value in setting up Gitbox just to be able to click a button to merge a PR. We don't use Github Issues/Labels which, I believe, is the primary reason this functionality came about. bq. perhaps we can just use Travis or Wercker for CI and forego having to use jenkins on ASF infra. Is Gitbox a requirement for using Travis/Wercker? Calcite and Avatica already use Travis.. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CALCITE-1421) Update website documentation to verify a release
[ https://issues.apache.org/jira/browse/CALCITE-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1421: Fix Version/s: (was: 1.13.0) 1.14.0 > Update website documentation to verify a release > > > Key: CALCITE-1421 > URL: https://issues.apache.org/jira/browse/CALCITE-1421 > Project: Calcite > Issue Type: Bug > Components: site >Affects Versions: 1.9.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > Fix For: 1.14.0 > > > Now we replace digest files with a single digest; thus, we need to update the > documentation for the way we validate the signature for the artifacts. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1847) Queries fail in the Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16078290#comment-16078290 ] Josh Elser commented on CALCITE-1847: - [~michaelmior], just double-checking, this JIRA issue should be resolved? > Queries fail in the Cassandra adapter > - > > Key: CALCITE-1847 > URL: https://issues.apache.org/jira/browse/CALCITE-1847 > Project: Calcite > Issue Type: Bug > Components: cassandra >Affects Versions: 1.13.0 >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.13.0 > > > It seems like there has been a change with when getRowType is called. Not > sure exactly what changed, but the Cassandra adapter relied on the old > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-1847) Queries fail in the Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1847. - Resolution: Fixed n/m, just going to close it for you :) Please open up a new one if there's more to do (to avoid confusion about what was done for a specific release). > Queries fail in the Cassandra adapter > - > > Key: CALCITE-1847 > URL: https://issues.apache.org/jira/browse/CALCITE-1847 > Project: Calcite > Issue Type: Bug > Components: cassandra >Affects Versions: 1.13.0 >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.13.0 > > > It seems like there has been a change with when getRowType is called. Not > sure exactly what changed, but the Cassandra adapter relied on the old > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-1877) Pig module generates test data outside of the target directory
[
https://issues.apache.org/jira/browse/CALCITE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1877.
-
Resolution: Fixed
Fixed in
https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=dac513ab446ad7cfed4be7858721659591134a00
Thanks for the review, Eli!
> Pig module generates test data outside of the target directory
> --
>
> Key: CALCITE-1877
> URL: https://issues.apache.org/jira/browse/CALCITE-1877
> Project: Calcite
> Issue Type: Bug
> Components: pig-adapter
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 1.14.0
>
>
> After running the unit tests in Calcite, you'll notice untracked files show
> up:
> {noformat}
> Untracked files:
> (use "git add ..." to include in what will be committed)
> pig/data.txt
> pig/data2.txt
> {noformat}
> We should make sure these make it into {{pig/target}} instead of just in
> {{pig}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1879) Consistent protobuf logging for protocol analysis
[ https://issues.apache.org/jira/browse/CALCITE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16078809#comment-16078809 ] Josh Elser commented on CALCITE-1879: - Generalizing, we already have all of the protobuf<->pojo logic encapsulated in ProtobufTranslationImpl. This is used by both client and server -- we should just make sure all code-paths in this class have the ability to print the protobuf messages at TRACE (rather than just client or just server). > Consistent protobuf logging for protocol analysis > - > > Key: CALCITE-1879 > URL: https://issues.apache.org/jira/browse/CALCITE-1879 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: avatica-1.11.0 > > > I had added logging to the Avatica server for the responses about to be sent > out, but it seems like I missed them for requests which were just received. > We should have both so that the Avatica server can be a single place to > inspect protocol issues. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1878) Ensure protobuf documentation is accurate following 1.10.0
Josh Elser created CALCITE-1878: --- Summary: Ensure protobuf documentation is accurate following 1.10.0 Key: CALCITE-1878 URL: https://issues.apache.org/jira/browse/CALCITE-1878 Project: Calcite Issue Type: Improvement Components: avatica, site Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.11.0 It was brought to my attention that the protobuf documentation was never updated for some of the protobuf related changes that were a part of Avatica-1.10.0. specifically: * CALCITE-1050 Array support for Avatica * CALCITE-1756 Differentiate between implicitly null and explicitly null TypedValues * CALCITE-1353 Convert first_frame_max_size to an int32 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1879) Log protobuf requests server-side
Josh Elser created CALCITE-1879: --- Summary: Log protobuf requests server-side Key: CALCITE-1879 URL: https://issues.apache.org/jira/browse/CALCITE-1879 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Trivial Fix For: avatica-1.11.0 I had added logging to the Avatica server for the responses about to be sent out, but it seems like I missed them for requests which were just received. We should have both so that the Avatica server can be a single place to inspect protocol issues. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-1878) Ensure protobuf documentation is accurate following 1.10.0
[ https://issues.apache.org/jira/browse/CALCITE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1878. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=7808cb8100ac44f6f26ae023a39ac1954f66f98f > Ensure protobuf documentation is accurate following 1.10.0 > -- > > Key: CALCITE-1878 > URL: https://issues.apache.org/jira/browse/CALCITE-1878 > Project: Calcite > Issue Type: Improvement > Components: avatica, site >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: avatica-1.11.0 > > > It was brought to my attention that the protobuf documentation was never > updated for some of the protobuf related changes that were a part of > Avatica-1.10.0. specifically: > * CALCITE-1050 Array support for Avatica > * CALCITE-1756 Differentiate between implicitly null and explicitly null > TypedValues > * CALCITE-1353 Convert first_frame_max_size to an int32 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-1880) Regenerate protobuf files
[ https://issues.apache.org/jira/browse/CALCITE-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1880. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=bf615c194f231b973458b63a231665016aad7a28 > Regenerate protobuf files > - > > Key: CALCITE-1880 > URL: https://issues.apache.org/jira/browse/CALCITE-1880 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: avatica-1.11.0 > > > Noticed that there are some minor things that the protobuf3.3.0 compiler > wants to change in the generated java files. Let's commit them to prevent > repeated dirtying of the workspace. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-1879) Consistent protobuf logging for protocol analysis
[ https://issues.apache.org/jira/browse/CALCITE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1879. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=4d0f397a71b9c43ca5962d3b7e87bcabdd6cc9f5 > Consistent protobuf logging for protocol analysis > - > > Key: CALCITE-1879 > URL: https://issues.apache.org/jira/browse/CALCITE-1879 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: avatica-1.11.0 > > > I had added logging to the Avatica server for the responses about to be sent > out, but it seems like I missed them for requests which were just received. > We should have both so that the Avatica server can be a single place to > inspect protocol issues. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1880) Regenerate protobuf files
Josh Elser created CALCITE-1880: --- Summary: Regenerate protobuf files Key: CALCITE-1880 URL: https://issues.apache.org/jira/browse/CALCITE-1880 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Trivial Fix For: avatica-1.11.0 Noticed that there are some minor things that the protobuf3.3.0 compiler wants to change in the generated java files. Let's commit them to prevent repeated dirtying of the workspace. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1877) Pig module generates test data outside of the target directory
Josh Elser created CALCITE-1877:
---
Summary: Pig module generates test data outside of the target
directory
Key: CALCITE-1877
URL: https://issues.apache.org/jira/browse/CALCITE-1877
Project: Calcite
Issue Type: Bug
Components: pig-adapter
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Trivial
Fix For: 1.14.0
After running the unit tests in Calcite, you'll notice untracked files show up:
{noformat}
Untracked files:
(use "git add ..." to include in what will be committed)
pig/data.txt
pig/data2.txt
{noformat}
We should make sure these make it into {{pig/target}} instead of just in
{{pig}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1815) Change Avatica dependency of the Pig adapter to avatica-core
[
https://issues.apache.org/jira/browse/CALCITE-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1815:
Component/s: pig-adapter
> Change Avatica dependency of the Pig adapter to avatica-core
>
>
> Key: CALCITE-1815
> URL: https://issues.apache.org/jira/browse/CALCITE-1815
> Project: Calcite
> Issue Type: Bug
> Components: pig-adapter
>Affects Versions: 1.12.0
>Reporter: Eli Levine
>Assignee: Eli Levine
> Fix For: 1.14.0
>
>
> Calcite-pig unnecessarily depends on the full {{avatica}} instead of
> {{avatica-core}}. This causes problems in some environments because
> {{avatica}} jar contains slf4j classes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094799#comment-16094799 ] Josh Elser commented on CALCITE-1240: - bq. 2. Is it possible to get a separate git repo for this? It makes it easier to import using Go's dependency tools like dep and the package structure would be more idiomatic. Yup bq. What is the process for getting the code into the Calcite/Avatica project? Essentially, we'll have to follow the IP Clearance process. https://incubator.apache.org/ip-clearance/index.html This isn't anything more than some formality in documenting: license compatibility, copyright assignment, and such. Working through the Go dependencies to make sure we follow ASF policies will be the biggest issue :) > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1902) boolean java.sql.ResultSet.previous() throws SQLException should throw SQLException, but it is throwing UnsupportedOperationException
[
https://issues.apache.org/jira/browse/CALCITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100163#comment-16100163
]
Josh Elser commented on CALCITE-1902:
-
Hi [~sergiosp]! Thanks for reporting the issue.
Looking at the javadoc on {{ResultSet#previous()}}, it instructs us to throw
{{SQLFeatureNotSupportedException}} if the driver doesn't support it, not a
bare {{SQLException}}.
Do you have interest in fixing this?
> boolean java.sql.ResultSet.previous() throws SQLException should throw
> SQLException, but it is throwing UnsupportedOperationException
> -
>
> Key: CALCITE-1902
> URL: https://issues.apache.org/jira/browse/CALCITE-1902
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.10.0
>Reporter: Sergio Sainz
>Priority: Minor
>
> boolean java.sql.ResultSet.previous() throws SQLException should throw
> SQLException, but it is throwing UnsupportedOperationException instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1904) Support disabling SSL hostname verification
[
https://issues.apache.org/jira/browse/CALCITE-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1904.
-
Resolution: Fixed
Resolved in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=c3f4611d4e94f50ed2130801c7054e3d109bde4b
> Support disabling SSL hostname verification
> ---
>
> Key: CALCITE-1904
> URL: https://issues.apache.org/jira/browse/CALCITE-1904
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
>
> Follow-on from CALCITE-1538:
> In testing environments, it may be beneficial to disable the standard
> hostname verification against SSL certificates: verification that the
> CommonName (CN) on the certificate matches the hostname of the server.
> Presently, if the CN on the certificate does not match the hostname, the
> client will see an error:
> {noformat}
> java.lang.RuntimeException: javax.net.ssl.SSLPeerUnverifiedException: Host
> name 'host1' does not match the certificate subject provided by the peer
> (CN=host2)
> at
> org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientImpl.send(AvaticaCommonsHttpClientImpl.java:169)
> at
> org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:45)
> at
> org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:81)
> at org.apache.calcite.avatica.remote.Driver.connect(Driver.java:176)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
> at
> sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
> at sqlline.Commands.connect(Commands.java:1064)
> at sqlline.Commands.connect(Commands.java:996)
> 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
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
> at sqlline.SqlLine.dispatch(SqlLine.java:804)
> at sqlline.SqlLine.initArgs(SqlLine.java:588)
> at sqlline.SqlLine.begin(SqlLine.java:656)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> at
> org.apache.phoenix.queryserver.client.SqllineWrapper$1.run(SqllineWrapper.java:88)
> at
> org.apache.phoenix.queryserver.client.SqllineWrapper$1.run(SqllineWrapper.java:85)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1866)
> at
> org.apache.phoenix.queryserver.client.SqllineWrapper.main(SqllineWrapper.java:85)
> Caused by: javax.net.ssl.SSLPeerUnverifiedException: Host name 'host1' does
> not match the certificate subject provided by the peer (CN=host2)
> at
> org.apache.calcite.avatica.org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:465)
> at
> org.apache.calcite.avatica.org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:395)
> at
> org.apache.calcite.avatica.org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
> at
> org.apache.calcite.avatica.org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:141)
> at
> org.apache.calcite.avatica.org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at
> org.apache.calcite.avatica.org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> 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:184)
> at
> org.apache.calcite.avatica.org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
>
[jira] [Commented] (CALCITE-1902) boolean java.sql.ResultSet.previous() throws SQLException should throw SQLException, but it is throwing UnsupportedOperationException
[ https://issues.apache.org/jira/browse/CALCITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103398#comment-16103398 ] Josh Elser commented on CALCITE-1902: - bq. Actually, I think I found the place to make the change: Yup! That's the class to change. I'd be more than happy to review a change from you! It seems like there are some other methods in that class as well that we could fix (UnsupportedOperationException to SQLFeatureNotSupportedException), such as https://github.com/apache/calcite-avatica/blob/master/core/src/main/java/org/apache/calcite/avatica/AvaticaResultSet.java#L516-L518 Take a look at https://calcite.apache.org/avatica/develop/#contributing on how we would like contributions. I'll go ahead and assign this issue to you so we can make sure no one else accidentally does it. > boolean java.sql.ResultSet.previous() throws SQLException should throw > SQLException, but it is throwing UnsupportedOperationException > - > > Key: CALCITE-1902 > URL: https://issues.apache.org/jira/browse/CALCITE-1902 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.10.0 >Reporter: Sergio Sainz >Priority: Minor > Fix For: avatica-1.11.0 > > > boolean java.sql.ResultSet.previous() throws SQLException should throw > SQLException, but it is throwing UnsupportedOperationException instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CALCITE-1902) boolean java.sql.ResultSet.previous() throws SQLException should throw SQLException, but it is throwing UnsupportedOperationException
[ https://issues.apache.org/jira/browse/CALCITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-1902: --- Assignee: Sergio Sainz > boolean java.sql.ResultSet.previous() throws SQLException should throw > SQLException, but it is throwing UnsupportedOperationException > - > > Key: CALCITE-1902 > URL: https://issues.apache.org/jira/browse/CALCITE-1902 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.10.0 >Reporter: Sergio Sainz >Assignee: Sergio Sainz >Priority: Minor > Fix For: avatica-1.11.0 > > > boolean java.sql.ResultSet.previous() throws SQLException should throw > SQLException, but it is throwing UnsupportedOperationException instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1904) Support disabling SSL hostname verification
Josh Elser created CALCITE-1904:
---
Summary: Support disabling SSL hostname verification
Key: CALCITE-1904
URL: https://issues.apache.org/jira/browse/CALCITE-1904
Project: Calcite
Issue Type: Improvement
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.11.0
Follow-on from CALCITE-1538:
In testing environments, it may be beneficial to disable the standard hostname
verification against SSL certificates: verification that the CommonName (CN) on
the certificate matches the hostname of the server. Presently, if the CN on the
certificate does not match the hostname, the client will see an error:
{noformat}
java.lang.RuntimeException: javax.net.ssl.SSLPeerUnverifiedException: Host name
'host1' does not match the certificate subject provided by the peer (CN=host2)
at
org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientImpl.send(AvaticaCommonsHttpClientImpl.java:169)
at
org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:45)
at
org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:81)
at org.apache.calcite.avatica.remote.Driver.connect(Driver.java:176)
at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
at sqlline.Commands.connect(Commands.java:1064)
at sqlline.Commands.connect(Commands.java:996)
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
sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
at sqlline.SqlLine.dispatch(SqlLine.java:804)
at sqlline.SqlLine.initArgs(SqlLine.java:588)
at sqlline.SqlLine.begin(SqlLine.java:656)
at sqlline.SqlLine.start(SqlLine.java:398)
at sqlline.SqlLine.main(SqlLine.java:292)
at
org.apache.phoenix.queryserver.client.SqllineWrapper$1.run(SqllineWrapper.java:88)
at
org.apache.phoenix.queryserver.client.SqllineWrapper$1.run(SqllineWrapper.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1866)
at
org.apache.phoenix.queryserver.client.SqllineWrapper.main(SqllineWrapper.java:85)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: Host name 'host1' does not
match the certificate subject provided by the peer (CN=host2)
at
org.apache.calcite.avatica.org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:465)
at
org.apache.calcite.avatica.org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:395)
at
org.apache.calcite.avatica.org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at
org.apache.calcite.avatica.org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:141)
at
org.apache.calcite.avatica.org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at
org.apache.calcite.avatica.org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
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:184)
at
org.apache.calcite.avatica.org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientImpl.execute(AvaticaCommonsHttpClientImpl.java:177)
at
org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientImpl.send(AvaticaCommonsHttpClientImpl.java:150)
... 23 more
{noformat}
Avatica should expose an option to disable the (default) strict hostname
verifier.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1487) Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after authentication failure
[
https://issues.apache.org/jira/browse/CALCITE-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102376#comment-16102376
]
Josh Elser commented on CALCITE-1487:
-
The {{baseRequest}} needs to be marked as "handled" -- that will prevent it
from filtering down to the other handlers that Jetty sets up (e.g. those
serving static files).
> Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after
> authentication failure
> -
>
> Key: CALCITE-1487
> URL: https://issues.apache.org/jira/browse/CALCITE-1487
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Labels: beginner
> Fix For: avatica-1.11.0
>
>
> I'm looking into a case where there are some authentication issues into an
> Avatica server. The SPNEGO handshake obviously failed via error in the
> server, but the client ultimately saw an HTTP/404 error which doesn't make
> sense (they should see a 401 or 403).
> I think I see why this happens. In the handlers, when the server is
> configured to require authenticated users and a user is not authenticated,
> the {{handle()}} method just returns.
> I believe the Handler implementation should set the Request as handled and
> set the appropriate response code. I believe the 404 is coming from the
> DefaultHandler (which has no html to serve for requests to "/").
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-1487) Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after authentication failure
[
https://issues.apache.org/jira/browse/CALCITE-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1487:
---
Assignee: Josh Elser
> Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after
> authentication failure
> -
>
> Key: CALCITE-1487
> URL: https://issues.apache.org/jira/browse/CALCITE-1487
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Labels: beginner
> Fix For: avatica-1.11.0
>
>
> I'm looking into a case where there are some authentication issues into an
> Avatica server. The SPNEGO handshake obviously failed via error in the
> server, but the client ultimately saw an HTTP/404 error which doesn't make
> sense (they should see a 401 or 403).
> I think I see why this happens. In the handlers, when the server is
> configured to require authenticated users and a user is not authenticated,
> the {{handle()}} method just returns.
> I believe the Handler implementation should set the Request as handled and
> set the appropriate response code. I believe the 404 is coming from the
> DefaultHandler (which has no html to serve for requests to "/").
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[ https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-1539. - Resolution: Fixed Commited in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=4db1fb9c66db8ccebc9e96ce678154ec69c557f0 I also added a quick blurb to the website to talk about this feature. Thanks for your contributions, [~Wancy]! > Enable proxy access to Avatica server for third party on behalf of end users > > > Key: CALCITE-1539 > URL: https://issues.apache.org/jira/browse/CALCITE-1539 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Jerry He >Assignee: Shi Wang > Fix For: avatica-1.10.0 > > Attachments: > 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch, > 0001-CALCITE-1539.patch, 0001-CALCITE-1539_without_testcase.patch > > > We want to enable proxy access to Avatica server from an end user, but the > end user comes in via a third party impersonation. For example, Knox and Hue. > The Knox server user conveys the end user to Avatica. > Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server > HIVE-5155 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1752) Use URLDecoder#decode to handle URLs acquired from getResource(..) calls in test cases
[
https://issues.apache.org/jira/browse/CALCITE-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983326#comment-15983326
]
Josh Elser commented on CALCITE-1752:
-
Fixed in Avatica in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=d9809ceef73b42f6662e2a195f7f8e7644058cab
> Use URLDecoder#decode to handle URLs acquired from getResource(..) calls in
> test cases
> --
>
> Key: CALCITE-1752
> URL: https://issues.apache.org/jira/browse/CALCITE-1752
> Project: Calcite
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.10.0, 1.13.0
>
>
> From
> https://github.com/apache/calcite/commit/6543c0fd8b63efb00d035790209f8546668d7aa5#commitcomment-21723380:
> [~michaelmior] suggested that it would be better to replace my
> {{String.replace("%20", " ")}} with {{java.net.URLDecoder.decode}} instead. I
> am apt to agree with him :)
> Maybe we can pull this into a utility instead of littering it around test
> cases in avatica and calcite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1050) Avatica can't serialize java.sql.Array
[
https://issues.apache.org/jira/browse/CALCITE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15981925#comment-15981925
]
Josh Elser commented on CALCITE-1050:
-
bq. Given the javadoc, I'd expect the above to work. For a TypedValue, I should
get an Object which is suitable to be set as an Array on the PreparedStatement.
However, the above throws a ClassCastException (trying to cast Object[] to
Array).
Alright, I have convinced myself that the current javadoc on TypedValue is
wrong. The reason we have not noticed this in the past is that HSQLDB will
"coerce" {{Object[]}} (non-primitive type arrays) and {{List}} into
columns of type {{ARRAY}}. For correctness: {{TypedValue.toJdbc(Calendar)}}
should return an {{Array}}, not a {{List}}. Databases that happened to still
work are just playing "nice".
> Avatica can't serialize java.sql.Array
> --
>
> Key: CALCITE-1050
> URL: https://issues.apache.org/jira/browse/CALCITE-1050
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.5.0
>Reporter: Lukas Lalinsky
>Assignee: Josh Elser
> Fix For: avatica-1.10.0
>
>
> As far as I can see, there is no way to serialize arrays in the Avatica RPC.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CALCITE-1752) Use URLDecoder#decode to handle URLs acquired from getResource(..) calls in test cases
[
https://issues.apache.org/jira/browse/CALCITE-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1752.
-
Resolution: Fixed
Fixed in Calcite in
https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=commit;h=478de569cf4b7084207b40ce957f47b6e8015fe7
> Use URLDecoder#decode to handle URLs acquired from getResource(..) calls in
> test cases
> --
>
> Key: CALCITE-1752
> URL: https://issues.apache.org/jira/browse/CALCITE-1752
> Project: Calcite
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.10.0, 1.13.0
>
>
> From
> https://github.com/apache/calcite/commit/6543c0fd8b63efb00d035790209f8546668d7aa5#commitcomment-21723380:
> [~michaelmior] suggested that it would be better to replace my
> {{String.replace("%20", " ")}} with {{java.net.URLDecoder.decode}} instead. I
> am apt to agree with him :)
> Maybe we can pull this into a utility instead of littering it around test
> cases in avatica and calcite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[ https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-1539: Fix Version/s: avatica-1.10.0 > Enable proxy access to Avatica server for third party on behalf of end users > > > Key: CALCITE-1539 > URL: https://issues.apache.org/jira/browse/CALCITE-1539 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Jerry He >Assignee: Shi Wang > Fix For: avatica-1.10.0 > > Attachments: > 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch, > 0001-CALCITE-1539.patch, 0001-CALCITE-1539_without_testcase.patch > > > We want to enable proxy access to Avatica server from an end user, but the > end user comes in via a third party impersonation. For example, Knox and Hue. > The Knox server user conveys the end user to Avatica. > Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server > HIVE-5155 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[
https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105381#comment-16105381
]
Josh Elser commented on CALCITE-1240:
-
bq. AFAICT, /repos/asf/incubator/donations doesn't exist. Is this a typo in the
template? What did you do when you handled previous IP clearance?
Hrm, that's interesting. I don't think I committed the granted codebase to SVN
before. Pulling up the old thread, I just hosted it in my ~elserj space on
people.a.o ("https://github.com/apache/incubator-slider/pull/3 or
http://people.apache.org/~elserj/KOYA-grant.patch; is specifically what I put
in the IP clearance XML form). I would say what you've done is sufficient --
someone can correct us during the lazy-consensus period if that is incorrect.
> Avatica client written in Golang
>
>
> Key: CALCITE-1240
> URL: https://issues.apache.org/jira/browse/CALCITE-1240
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Add a client for Avatica written in the Go language (aka "Golang").
> There is one at https://github.com/Boostport/avatica and the author has
> offered to contribute it.
> The driver is currently somewhat specialized for Phoenix but our goal should
> be to allow it to work against any Avatica provider (without diminishing its
> value to Phoenix users).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1240) Avatica client written in Golang
[
https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105381#comment-16105381
]
Josh Elser edited comment on CALCITE-1240 at 7/28/17 5:59 PM:
--
bq. AFAICT, /repos/asf/incubator/donations doesn't exist. Is this a typo in the
template? What did you do when you handled previous IP clearance?
Hrm, that's interesting. I don't think I committed the granted codebase to SVN
before. Pulling up the old thread, I just hosted it in my ~elserj space on
people.a.o ("https://github.com/apache/incubator-slider/pull/3 or
http://people.apache.org/~elserj/KOYA-grant.patch; is specifically what I put
in the IP clearance XML form). I would say what you've done is sufficient --
someone can correct us during the lazy-consensus period if that is incorrect.
Here's the form I filled out last time if helpful:
https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/slider-koya.xml
was (Author: elserj):
bq. AFAICT, /repos/asf/incubator/donations doesn't exist. Is this a typo in the
template? What did you do when you handled previous IP clearance?
Hrm, that's interesting. I don't think I committed the granted codebase to SVN
before. Pulling up the old thread, I just hosted it in my ~elserj space on
people.a.o ("https://github.com/apache/incubator-slider/pull/3 or
http://people.apache.org/~elserj/KOYA-grant.patch; is specifically what I put
in the IP clearance XML form). I would say what you've done is sufficient --
someone can correct us during the lazy-consensus period if that is incorrect.
> Avatica client written in Golang
>
>
> Key: CALCITE-1240
> URL: https://issues.apache.org/jira/browse/CALCITE-1240
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Add a client for Avatica written in the Go language (aka "Golang").
> There is one at https://github.com/Boostport/avatica and the author has
> offered to contribute it.
> The driver is currently somewhat specialized for Phoenix but our goal should
> be to allow it to work against any Avatica provider (without diminishing its
> value to Phoenix users).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120734#comment-16120734 ] Josh Elser commented on CALCITE-1240: - bq. CI is important, but let's deal with it in a separate case. I think adding Apache headers is the only change necessary before this PR can go in. Agreed. bq. Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured? You can do it this route if you'd like, but I don't have much experience. For the other Jenkins jobs for Calcite and Avatica, I've just created the jobs by hand. It is just an administrative task to get you an account. I believe there's at least one person in HBase who has experience doing this against their master branch. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118420#comment-16118420 ] Josh Elser commented on CALCITE-1240: - bq. Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github. Correct. The canonical repository is hosted on git-wip-us.apache.org. The Github "version" is just a copy/mirror for convenience. bq. it won't let me open a PR against apache/calcite-avatica-go. That does seem like a problem. Let me see what I can do. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[
https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118436#comment-16118436
]
Josh Elser commented on CALCITE-1240:
-
[~francischuang], I pushed an initial commit that adds a basic LICENSE and
NOTICE file to the repository.
You should be able to create a fork from the apache/calcite-avatica-go
repository now. You can create a pull-request, but you would still need to
commit it via the canonical repository
https://git-wip-us.apache.org/repos/asf/calcite-avatica-go.git
Typically what I have is multiple remotes set up for a git repository:
* Origin points to the canonical ASF repository
* {{joshelser}} points to my GH fork of the repository on the {{apache}} org on
Github
So, you can {{git-fetch}} your changes from your personal GH, merge it into
{{master}} locally, and then push it to {{origin}} (canonical ASF repo).
> Avatica client written in Golang
>
>
> Key: CALCITE-1240
> URL: https://issues.apache.org/jira/browse/CALCITE-1240
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Add a client for Avatica written in the Go language (aka "Golang").
> There is one at https://github.com/Boostport/avatica and the author has
> offered to contribute it.
> The driver is currently somewhat specialized for Phoenix but our goal should
> be to allow it to work against any Avatica provider (without diminishing its
> value to Phoenix users).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[
https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118427#comment-16118427
]
Josh Elser commented on CALCITE-1240:
-
{quote}
I currently use Wercker for CI. Can wercker be used on Apache repos?
I use goveralls for code coverage reports. Can it be used on Apache repos?
{quote}
Ideally, it would be better to not rely on external systems, but I don't
believe there is a reason we cannot use them.
It would be good to transition to the ASF Jenkins server(s) for CI so that all
members of Calcite can improve it.
For code-coverage, using this as a tool is fine, IMO. There are some tools
which may be available at the ASF already, but I'm not sure how they compare
WRT features. Is there a non-hosted options that developers could run on their
own?
> Avatica client written in Golang
>
>
> Key: CALCITE-1240
> URL: https://issues.apache.org/jira/browse/CALCITE-1240
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Add a client for Avatica written in the Go language (aka "Golang").
> There is one at https://github.com/Boostport/avatica and the author has
> offered to contribute it.
> The driver is currently somewhat specialized for Phoenix but our goal should
> be to allow it to work against any Avatica provider (without diminishing its
> value to Phoenix users).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117182#comment-16117182 ] Josh Elser commented on CALCITE-1240: - The canonical ASF repo is live at https://git-wip-us.apache.org/repos/asf?p=calcite-avatica-go.git The Github mirror is still in the process of being created, but should show up [here|https://github.com/apache?utf8=%E2%9C%93=calcite==] eventually > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-1487) Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after authentication failure
[
https://issues.apache.org/jira/browse/CALCITE-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1487.
-
Resolution: Fixed
Resolved in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=e5ad503858c47b4336adbb1ade8399818a9323d1
with a little unit test.
> Avatica{Json,Protobuf}Handler inadvertently returns HTTP/404 after
> authentication failure
> -
>
> Key: CALCITE-1487
> URL: https://issues.apache.org/jira/browse/CALCITE-1487
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Labels: beginner
> Fix For: avatica-1.11.0
>
>
> I'm looking into a case where there are some authentication issues into an
> Avatica server. The SPNEGO handshake obviously failed via error in the
> server, but the client ultimately saw an HTTP/404 error which doesn't make
> sense (they should see a 401 or 403).
> I think I see why this happens. In the handlers, when the server is
> configured to require authenticated users and a user is not authenticated,
> the {{handle()}} method just returns.
> I believe the Handler implementation should set the Request as handled and
> set the appropriate response code. I believe the 404 is coming from the
> DefaultHandler (which has no html to serve for requests to "/").
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116813#comment-16116813 ] Josh Elser commented on CALCITE-1240: - I'm not seeing it either. Maybe INFRA just meant that they fixed the reporeq tool and didn't actually create the repo for you, [~julianhyde]? I can create it too -- I just don't want to cause a race-condition between us :) > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1955) Cannot insert blob into Avatica-HSQLDB table because table is read only
[
https://issues.apache.org/jira/browse/CALCITE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133896#comment-16133896
]
Josh Elser commented on CALCITE-1955:
-
Nope, not onerous! After initial configuration (via request to INFRA) it just
happens automatically. My only concern would be whether or not it's necessary
to have two, e.g. is it somehow possible to load the scott dataset in a r/w
manner instead of as a catalog? I just don't know enough about hysqldb to say
one way or the other.
> Cannot insert blob into Avatica-HSQLDB table because table is read only
> ---
>
> Key: CALCITE-1955
> URL: https://issues.apache.org/jira/browse/CALCITE-1955
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>
> This might be more of a question as I am not able to find official
> information in the HSQLDB docs.
> I am porting a test to test the insertion of binary data into a table from
> Phoenix to HSQLDB. The test passes when using Phoenix with avatica.
> 1. I created this table:
> {code}
> CREATE TABLE some_table (
> int INTEGER PRIMARY KEY,
> bin BLOB
> )
> {code}
> 2. I attempt to insert the data using `INSERT INTO some_table (int, bin)
> VALUES (?, ?)`
> The binary is being sent as a `Rep_BYTE_STRING` and the data is placed in
> byte_values.
> This is the error I receive from HSQLDB:
> {code}
> RuntimeException: java.sql.SQLException: org.hsqldb.HsqlException: The table
> data is read only -> SQLException: org.hsqldb.HsqlException: The table data
> is read only -> HsqlException: org.hsqldb.HsqlException: The table data is
> read only -> HsqlException: The table data is read only
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1955) Cannot insert blob into Avatica-HSQLDB table because table is read only
[
https://issues.apache.org/jira/browse/CALCITE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16131723#comment-16131723
]
Josh Elser commented on CALCITE-1955:
-
Not sure, [~francischuang]. Most of my acquired knowledge of hsqldb has been
around messing with it in unit tests via Avatica testing.
I'm a bit swamped with dayjob responsibility at present -- you may be on your
own to debug for a little bit (maybe someone who knows more will see your plea
though ;)).
> Cannot insert blob into Avatica-HSQLDB table because table is read only
> ---
>
> Key: CALCITE-1955
> URL: https://issues.apache.org/jira/browse/CALCITE-1955
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> This might be more of a question as I am not able to find official
> information in the HSQLDB docs.
> I am porting a test to test the insertion of binary data into a table from
> Phoenix to HSQLDB. The test passes when using Phoenix with avatica.
> 1. I created this table:
> {code}
> CREATE TABLE some_table (
> int INTEGER PRIMARY KEY,
> bin BLOB
> )
> {code}
> 2. I attempt to insert the data using `INSERT INTO some_table (int, bin)
> VALUES (?, ?)`
> The binary is being sent as a `Rep_BYTE_STRING` and the data is placed in
> byte_values.
> This is the error I receive from HSQLDB:
> {code}
> RuntimeException: java.sql.SQLException: org.hsqldb.HsqlException: The table
> data is read only -> SQLException: org.hsqldb.HsqlException: The table data
> is read only -> HsqlException: org.hsqldb.HsqlException: The table data is
> read only -> HsqlException: The table data is read only
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-1955) Cannot insert blob into Avatica-HSQLDB table because table is read only
[
https://issues.apache.org/jira/browse/CALCITE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1955:
---
Assignee: (was: Josh Elser)
> Cannot insert blob into Avatica-HSQLDB table because table is read only
> ---
>
> Key: CALCITE-1955
> URL: https://issues.apache.org/jira/browse/CALCITE-1955
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>
> This might be more of a question as I am not able to find official
> information in the HSQLDB docs.
> I am porting a test to test the insertion of binary data into a table from
> Phoenix to HSQLDB. The test passes when using Phoenix with avatica.
> 1. I created this table:
> {code}
> CREATE TABLE some_table (
> int INTEGER PRIMARY KEY,
> bin BLOB
> )
> {code}
> 2. I attempt to insert the data using `INSERT INTO some_table (int, bin)
> VALUES (?, ?)`
> The binary is being sent as a `Rep_BYTE_STRING` and the data is placed in
> byte_values.
> This is the error I receive from HSQLDB:
> {code}
> RuntimeException: java.sql.SQLException: org.hsqldb.HsqlException: The table
> data is read only -> SQLException: org.hsqldb.HsqlException: The table data
> is read only -> HsqlException: org.hsqldb.HsqlException: The table data is
> read only -> HsqlException: The table data is read only
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1951) Avatica HSQLDB docker image time loses fractional seconds
[
https://issues.apache.org/jira/browse/CALCITE-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16131724#comment-16131724
]
Josh Elser commented on CALCITE-1951:
-
bq. According to the guide on data types
(http://hsqldb.org/doc/2.0/guide/sqlgeneral-chapt.html#sgc_data_type_guide),
defining a field as TIME(6) should have 6 fractional seconds for the field. By
default it is 0, but I've set it to 6 in my table definition.
Ok, that seems to point towards it being an Avatica bug. A unit test would
likely be the next step to try to get to the bottom of it!
> Avatica HSQLDB docker image time loses fractional seconds
> -
>
> Key: CALCITE-1951
> URL: https://issues.apache.org/jira/browse/CALCITE-1951
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> I create a table like so in HSQLDB using the avatica-hsqldb image:
> {code}
> CREATE TABLE some_table (
> tm TIME(6) PRIMARY KEY,
> )
> {code}
> I then use calculate the milliseconds since 00:00:00.000 and send this value
> along with my insert statement: 76881222
> However, when I select the row to read the value back, I get 76881000.
> In this case, 222 milliseconds was lost.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-1951) Avatica HSQLDB docker image time loses fractional seconds
[
https://issues.apache.org/jira/browse/CALCITE-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1951:
---
Assignee: (was: Josh Elser)
> Avatica HSQLDB docker image time loses fractional seconds
> -
>
> Key: CALCITE-1951
> URL: https://issues.apache.org/jira/browse/CALCITE-1951
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>
> I create a table like so in HSQLDB using the avatica-hsqldb image:
> {code}
> CREATE TABLE some_table (
> tm TIME(6) PRIMARY KEY,
> )
> {code}
> I then use calculate the milliseconds since 00:00:00.000 and send this value
> along with my insert statement: 76881222
> However, when I select the row to read the value back, I get 76881000.
> In this case, 222 milliseconds was lost.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1951) Avatica HSQLDB docker image time loses fractional seconds
[
https://issues.apache.org/jira/browse/CALCITE-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130747#comment-16130747
]
Josh Elser commented on CALCITE-1951:
-
Any chance you could write a unit test that shows this? It's hard to say if
this is an avatica bug or just how hsqldb works.
> Avatica HSQLDB docker image time loses fractional seconds
> -
>
> Key: CALCITE-1951
> URL: https://issues.apache.org/jira/browse/CALCITE-1951
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>Assignee: Josh Elser
>
> I create a table like so in HSQLDB using the avatica-hsqldb image:
> {code}
> CREATE TABLE some_table (
> tm TIME(6) PRIMARY KEY,
> )
> {code}
> I then use calculate the milliseconds since 00:00:00.000 and send this value
> along with my insert statement: 76881222
> However, when I select the row to read the value back, I get 76881000.
> In this case, 222 milliseconds was lost.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-1612) Release Avatica 1.10
[ https://issues.apache.org/jira/browse/CALCITE-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-1612: --- Assignee: Josh Elser > Release Avatica 1.10 > > > Key: CALCITE-1612 > URL: https://issues.apache.org/jira/browse/CALCITE-1612 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Josh Elser > Fix For: avatica-1.10.0 > > > Parent issue to track things to do for this release, and issues in other > projects that depend on the release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CALCITE-1813) Wrong dependency management entry for avatica-noop-driver
[
https://issues.apache.org/jira/browse/CALCITE-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1813:
Priority: Trivial (was: Major)
> Wrong dependency management entry for avatica-noop-driver
> -
>
> Key: CALCITE-1813
> URL: https://issues.apache.org/jira/browse/CALCITE-1813
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.11.0
>
>
> Looking into a site generation issue that Julian asked about, I noticed that
> the dependency for {{avatica-noop-driver}} is incorrectly listed as
> {{avatica-noop}} in the parent pom.xml which breaks javadoc generation (or
> maybe it was checkstyle). Doesn't actually cause a compilation breakage, so
> it went unnoticed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CALCITE-1813) Wrong dependency management entry for avatica-noop-driver
[
https://issues.apache.org/jira/browse/CALCITE-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1813.
-
Resolution: Fixed
Trivial little fix
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=57b57ec1bd7281dc5131b0c9602c62ca8b0b961b
> Wrong dependency management entry for avatica-noop-driver
> -
>
> Key: CALCITE-1813
> URL: https://issues.apache.org/jira/browse/CALCITE-1813
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.11.0
>
>
> Looking into a site generation issue that Julian asked about, I noticed that
> the dependency for {{avatica-noop-driver}} is incorrectly listed as
> {{avatica-noop}} in the parent pom.xml which breaks javadoc generation (or
> maybe it was checkstyle). Doesn't actually cause a compilation breakage, so
> it went unnoticed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1813) Wrong dependency management entry for avatica-noop-driver
Josh Elser created CALCITE-1813:
---
Summary: Wrong dependency management entry for avatica-noop-driver
Key: CALCITE-1813
URL: https://issues.apache.org/jira/browse/CALCITE-1813
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.11.0
Looking into a site generation issue that Julian asked about, I noticed that
the dependency for {{avatica-noop-driver}} is incorrectly listed as
{{avatica-noop}} in the parent pom.xml which breaks javadoc generation (or
maybe it was checkstyle). Doesn't actually cause a compilation breakage, so it
went unnoticed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1836) Upgrade to protobuf 3.3.0
Josh Elser created CALCITE-1836: --- Summary: Upgrade to protobuf 3.3.0 Key: CALCITE-1836 URL: https://issues.apache.org/jira/browse/CALCITE-1836 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.11.0 Protobuf-java 3.3.0 came out last month and looks like it has some nice improvements. We should upgrade to it. There appear to be no advertised incompatibilities across releases. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051182#comment-16051182
]
Josh Elser commented on CALCITE-1195:
-
Nice! Thanks for sharing that, Kevin.
Would you mind if I add this to the website?
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1195.
-
Resolution: Fixed
Committed in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=0020a547c845cc27f7dc048f2b8ac7cb83dc53e0
I published it at https://calcite.apache.org/avatica/docs/protocol_testing.html
after verifying that it works against the hsqldb avatica-1.10.0 docker image.
While there's always more we can do, this is a bit too broad to get anywhere
more with it. I should try to make more focused doc tickets in the future :)
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1195:
---
Assignee: Kevin Risden (was: Josh Elser)
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051303#comment-16051303
]
Josh Elser commented on CALCITE-1195:
-
You're also now marked as a contributor, [~risdenk] :)
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1811) Work around "latest" tag for Docker images
Josh Elser created CALCITE-1811:
---
Summary: 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.11.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
(v6.3.15#6346)
[jira] [Created] (CALCITE-2003) Avoid global synchronization around openConnection in JdbcMeta
Josh Elser created CALCITE-2003:
---
Summary: Avoid global synchronization around openConnection in
JdbcMeta
Key: CALCITE-2003
URL: https://issues.apache.org/jira/browse/CALCITE-2003
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: avatica-1.11.0
Had a report from a user where opening new connections to Avatica were stuck.
Upon investigation, there was a single thread which had grabbed the local on
the JdbcMeta instance in {{JdbcMeta#openConnection(ConnectionHandle)}}, but was
not returning out of the {{DriverManager.getConnection(...)}} call.
Using the {{ConcurrentMap}} API over the Guava {{Cache}} API gives us enough
flexibility that we can handle this safely without the total synchronization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2003) Avoid global synchronization around openConnection in JdbcMeta
[
https://issues.apache.org/jira/browse/CALCITE-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-2003:
Issue Type: Improvement (was: Bug)
> Avoid global synchronization around openConnection in JdbcMeta
> --
>
> Key: CALCITE-2003
> URL: https://issues.apache.org/jira/browse/CALCITE-2003
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
>
> Had a report from a user where opening new connections to Avatica were stuck.
> Upon investigation, there was a single thread which had grabbed the local on
> the JdbcMeta instance in {{JdbcMeta#openConnection(ConnectionHandle)}}, but
> was not returning out of the {{DriverManager.getConnection(...)}} call.
> Using the {{ConcurrentMap}} API over the Guava {{Cache}} API gives us enough
> flexibility that we can handle this safely without the total synchronization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179164#comment-16179164 ] Josh Elser commented on CALCITE-1938: - No worries on timing, Francis. We all get busy :) bq. HSQLDB does not seem to be very stable What do you mean? It's worked fine for how I've used it. If you're having specific troubles, Julian or myself can likely give a recommendation. We use hsqldb quite extensively in tests already -- I'd be surprised if it has some major limitation. bq. What is the Apache foundation's stance on spinning up an instance of MySQL for tests MySQL and MariaDB are GPL licensed. So, we would not be able to bundle them in any release. I believe we would be allowed to have test-only automation which installs/runs them, but I'm not positive. [~julianhyde] might remember more what policy states off the top of his head (else, I'll have to go digging). > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1955) Cannot insert blob into Avatica-HSQLDB table because table is read only
[
https://issues.apache.org/jira/browse/CALCITE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133198#comment-16133198
]
Josh Elser commented on CALCITE-1955:
-
Good find!
bq. So I guess in this case, we just need to update the documentation for
Avatica-HSQLDB to state that it is launched with the scott dataset by default
which is not writeable for LOBs.
We could also consider publishing more than one image: one that is just the
read-only scott dataset and another which is the normal memory-backed
implementation. Do you think that would be helpful?
> Cannot insert blob into Avatica-HSQLDB table because table is read only
> ---
>
> Key: CALCITE-1955
> URL: https://issues.apache.org/jira/browse/CALCITE-1955
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Francis Chuang
>
> This might be more of a question as I am not able to find official
> information in the HSQLDB docs.
> I am porting a test to test the insertion of binary data into a table from
> Phoenix to HSQLDB. The test passes when using Phoenix with avatica.
> 1. I created this table:
> {code}
> CREATE TABLE some_table (
> int INTEGER PRIMARY KEY,
> bin BLOB
> )
> {code}
> 2. I attempt to insert the data using `INSERT INTO some_table (int, bin)
> VALUES (?, ?)`
> The binary is being sent as a `Rep_BYTE_STRING` and the data is placed in
> byte_values.
> This is the error I receive from HSQLDB:
> {code}
> RuntimeException: java.sql.SQLException: org.hsqldb.HsqlException: The table
> data is read only -> SQLException: org.hsqldb.HsqlException: The table data
> is read only -> HsqlException: org.hsqldb.HsqlException: The table data is
> read only -> HsqlException: The table data is read only
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-2003) Avoid global synchronization around openConnection in JdbcMeta
[
https://issues.apache.org/jira/browse/CALCITE-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-2003.
-
Resolution: Fixed
Fixed in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=fcb1342a404a38b14ddefb1f4d81fd2c4c953718
> Avoid global synchronization around openConnection in JdbcMeta
> --
>
> Key: CALCITE-2003
> URL: https://issues.apache.org/jira/browse/CALCITE-2003
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
>
> Had a report from a user where opening new connections to Avatica were stuck.
> Upon investigation, there was a single thread which had grabbed the local on
> the JdbcMeta instance in {{JdbcMeta#openConnection(ConnectionHandle)}}, but
> was not returning out of the {{DriverManager.getConnection(...)}} call.
> Using the {{ConcurrentMap}} API over the Guava {{Cache}} API gives us enough
> flexibility that we can handle this safely without the total synchronization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-2065) Make “autoCommit” an accepted parameter in the JDBC URL
[ https://issues.apache.org/jira/browse/CALCITE-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-2065: --- Assignee: Josh Elser > Make “autoCommit” an accepted parameter in the JDBC URL > --- > > Key: CALCITE-2065 > URL: https://issues.apache.org/jira/browse/CALCITE-2065 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Christian Tzolov >Assignee: Josh Elser > > At the moment there is no declarative way to set connection's "autoCommit" > property. It defaults to `false`. > There are couple of use cases (like apache zeppelin integration) where the > ability to set the autocommit property to true are required. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2073) Allow disabling of protobuf generation
Josh Elser created CALCITE-2073: --- Summary: Allow disabling of protobuf generation Key: CALCITE-2073 URL: https://issues.apache.org/jira/browse/CALCITE-2073 Project: Calcite Issue Type: Task Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Trivial Fix For: avatica-1.11.0 The xolstice maven-protobuf-plugin has a runtime dependency on a specific glibc version which fails on older OS versions (notably Centos6). For most builds, it's unnecessary to regenerate the protobuf "specs" into Java code. We can add an option for individuals to disable this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-2073) Allow disabling of protobuf generation
[ https://issues.apache.org/jira/browse/CALCITE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-2073. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=cc3605e2af6ee242c70f72e330f2c12a77b8bf44 > Allow disabling of protobuf generation > -- > > Key: CALCITE-2073 > URL: https://issues.apache.org/jira/browse/CALCITE-2073 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: avatica-1.11.0 > > > The xolstice maven-protobuf-plugin has a runtime dependency on a specific > glibc version which fails on older OS versions (notably Centos6). > For most builds, it's unnecessary to regenerate the protobuf "specs" into > Java code. We can add an option for individuals to disable this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2027) Drop support for Java 7 (JDK 1.7)
[ https://issues.apache.org/jira/browse/CALCITE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238562#comment-16238562 ] Josh Elser commented on CALCITE-2027: - bq. Staying on old versions of components seems to be asking for problems such as security bugs, but when you upgrade you get scowls from other projects about causing incompatibility. Surely there's a better way?! :) that's the trick, isn't it. My opinion has changed over the years, most recently influenced by some of your decisions on Calcite, actually. My general thought process is this: * Minimize dependencies that are "visible" to your downstream components. * With JARs that don't have any shading (e.g. calcite-core), curate the list of dependencies that it requires and versions that we know work with it. We always have at least one version that we know is compatible. This enables downstream folks who *want* to minimize the size of an application to do so. * For "client-side" dependencies, publish a shaded artifact that includes as many dependencies as possible relocated to make sure your client can work regardless of classpath (things like loggers suck as you often can't relocate safely). This enables folks who "don't care" to just solve classpath conflict issues via a large application disk usage. * For "server-side" things, if you're sure that the "server" doesn't run inside of anything else, do nothing. e.g. Avatica with the Jetty server is self-contained, so dependency compatibility isn't a concern. However, if we think of Avatica as a container which could be deployed into Tomcat or JBoss, then we need to do the same as we do for "client-side". https://www.elastic.co/blog/to-shade-or-not-to-shade is a nice little post that covers the consequences of shading well. The biggest concern with shading dependencies into an artifact that we publish is that this puts an onus on Calcite to watch for security issues in every dependency that we bundle. We're more like a an operating-system packager at this point -- e.g. if Calcite bundles guava in a shaded jar and there is a Guava CVE, we need to make a new release of Calcite that includes the patched Guava version. This is all a long winded way of getting Calcite into a place where we _don't have to care_ when we upgrade dependencies. We can choose to upgrade them at our choosing, because there is no impact on those downstream. We're in charge of our own destiny :) > Drop support for Java 7 (JDK 1.7) > - > > Key: CALCITE-2027 > URL: https://issues.apache.org/jira/browse/CALCITE-2027 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Drop support for Java 7 (also known as JDK 1.7): > * The code would no longer compile under JDK 7 > * Compiler would have source 1.8 target 1.8 > * Class files would run on JDK 8 and higher > * Developers can use Java 8 syntax such as lambdas and default methods > We would continue to build and run under JDK 8 and 9. > I think it would be best to wait a while before converting existing code to > Java 8 style (e.g. converting SAM anonymous classes to lambdas) because code > changes might be extensive. > I expect there will be cases that we want to change interfaces so that they > are easier to use as lambdas. Let's make those changes cautiously when we > come across them, and mark existing interfaces and methods deprecated until > we remove them in 2.0. > Let's give at least one release notice of this change. In 1.15 (the next > release) let's announce that this will be the last release that supports Java > 7. So this will be fixed for 1.16. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2027) Drop support for Java 7 (JDK 1.7)
[ https://issues.apache.org/jira/browse/CALCITE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238490#comment-16238490 ] Josh Elser commented on CALCITE-2027: - Exciting stuff :) Sounds good, Julian! > Drop support for Java 7 (JDK 1.7) > - > > Key: CALCITE-2027 > URL: https://issues.apache.org/jira/browse/CALCITE-2027 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Drop support for Java 7 (also known as JDK 1.7): > * The code would no longer compile under JDK 7 > * Compiler would have source 1.8 target 1.8 > * Class files would run on JDK 8 and higher > * Developers can use Java 8 syntax such as lambdas and default methods > We would continue to build and run under JDK 8 and 9. > I think it would be best to wait a while before converting existing code to > Java 8 style (e.g. converting SAM anonymous classes to lambdas) because code > changes might be extensive. > I expect there will be cases that we want to change interfaces so that they > are easier to use as lambdas. Let's make those changes cautiously when we > come across them, and mark existing interfaces and methods deprecated until > we remove them in 2.0. > Let's give at least one release notice of this change. In 1.15 (the next > release) let's announce that this will be the last release that supports Java > 7. So this will be fixed for 1.16. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-2086) HTTP/413 in certain circumstances due to large Authorization headers
[ https://issues.apache.org/jira/browse/CALCITE-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-2086. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=160e1a9382935997ba5a5ae42510d32734b76906 > HTTP/413 in certain circumstances due to large Authorization headers > > > Key: CALCITE-2086 > URL: https://issues.apache.org/jira/browse/CALCITE-2086 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.11.0 > > > Had a user case where a certain user's requests to an Avatica server were met > with an HTTP/413 error because the Authorization header was larger than the > default allowed 8KB. I'm not sure of the exact circumstances, but something > is "special" about the user's Kerberos key (SPNEGO-based auth). > We should allow this to be configurable by the Avatica server and also > increase the default (64KB should be more than enough for the present and > would avoid more downstream changes). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2086) HTTP/413 in certain circumstances due to large Authorization headers
Josh Elser created CALCITE-2086: --- Summary: HTTP/413 in certain circumstances due to large Authorization headers Key: CALCITE-2086 URL: https://issues.apache.org/jira/browse/CALCITE-2086 Project: Calcite Issue Type: Bug Components: avatica Reporter: Josh Elser Assignee: Josh Elser Priority: Critical Fix For: avatica-1.11.0 Had a user case where a certain user's requests to an Avatica server were met with an HTTP/413 error because the Authorization header was larger than the default allowed 8KB. I'm not sure of the exact circumstances, but something is "special" about the user's Kerberos key (SPNEGO-based auth). We should allow this to be configurable by the Avatica server and also increase the default (64KB should be more than enough for the present and would avoid more downstream changes). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2086) HTTP/413 in certain circumstances due to large Authorization headers
[ https://issues.apache.org/jira/browse/CALCITE-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16287103#comment-16287103 ] Josh Elser commented on CALCITE-2086: - Thanks, Kevin! I have an ask out to this user for some more details :). Your context is appreciated! > HTTP/413 in certain circumstances due to large Authorization headers > > > Key: CALCITE-2086 > URL: https://issues.apache.org/jira/browse/CALCITE-2086 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.11.0 > > > Had a user case where a certain user's requests to an Avatica server were met > with an HTTP/413 error because the Authorization header was larger than the > default allowed 8KB. I'm not sure of the exact circumstances, but something > is "special" about the user's Kerberos key (SPNEGO-based auth). > We should allow this to be configurable by the Avatica server and also > increase the default (64KB should be more than enough for the present and > would avoid more downstream changes). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2013) Bump HSQLDB version in avatica
[ https://issues.apache.org/jira/browse/CALCITE-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219029#comment-16219029 ] Josh Elser commented on CALCITE-2013: - bq. I bumped hsqldb in pom.mxl to 2.4.0, but the tests are failing: Curious. I'll try to find some time to look at this. > Bump HSQLDB version in avatica > -- > > Key: CALCITE-2013 > URL: https://issues.apache.org/jira/browse/CALCITE-2013 > Project: Calcite > Issue Type: Improvement > Components: avatica >Affects Versions: avatica-1.10.0 >Reporter: Francis Chuang >Priority: Minor > > It would be nice if the HSQLDB used in avatica can be bumped to the latest > version. The 2.4.x series was released around 6 months ago and should be > quite stable. 2.3.1 which is currently being used is around 4 years old and > there has been a lot of bug fixes since. > I ran into a bunch of issues while testing the avatica-go driver against > HSQLDB and I am hoping an upgrade to 2.4.x will resolve some or most of the > issues. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2022) ConnectionConfigImplTest failing on Jenkins
Josh Elser created CALCITE-2022:
---
Summary: ConnectionConfigImplTest failing on Jenkins
Key: CALCITE-2022
URL: https://issues.apache.org/jira/browse/CALCITE-2022
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Minor
Fix For: avatica-1.11.0
{noformat}
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec <<<
FAILURE! - in org.apache.calcite.avatica.ConnectionConfigImplTest
testTrustStore(org.apache.calcite.avatica.ConnectionConfigImplTest) Time
elapsed: 0.015 sec <<< FAILURE!
java.lang.AssertionError:
Expected: is "C:\my\truststore.jks"
but: was "F:\my\truststore.jks"
at
org.apache.calcite.avatica.ConnectionConfigImplTest.testTrustStore(ConnectionConfigImplTest.java:41)
{noformat}
Looks like a pretty simple test failure on Windows that Jenkins caught for us.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-2017) Automatic Kerberos login fails on IBM Java
[
https://issues.apache.org/jira/browse/CALCITE-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-2017.
-
Resolution: Fixed
Fixed in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=2de4b19223aded0212b5dd20c051b881808bdb24
Had to do a force-push because I tried to close the pull-request with the
travis-ci build number. Oops.
> Automatic Kerberos login fails on IBM Java
> --
>
> Key: CALCITE-2017
> URL: https://issues.apache.org/jira/browse/CALCITE-2017
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
>
> Had a report come in from a user.
> Apparently when performing a JAAS login with Krb5LoginModule, Oracle Java
> uses the option {{isInitiator}} whereas IBM Java uses {{credType}}. This
> results is the automatic Kerberos login to fail on IBM Java.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2017) Automatic Kerberos login fails on IBM Java
[
https://issues.apache.org/jira/browse/CALCITE-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1621#comment-1621
]
Josh Elser commented on CALCITE-2017:
-
These changes get {{mvn verify}} running on both Oracle Java 1.8.0_131 and IBM
Java {{J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References
20170901_363591 (JIT enabled, AOT enabled)}}, as well as Oracle Java {{Java(TM)
SE Runtime Environment (build 1.7.0_79-b15)}} (if anyone still cares about
that).
> Automatic Kerberos login fails on IBM Java
> --
>
> Key: CALCITE-2017
> URL: https://issues.apache.org/jira/browse/CALCITE-2017
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
>
> Had a report come in from a user.
> Apparently when performing a JAAS login with Krb5LoginModule, Oracle Java
> uses the option {{isInitiator}} whereas IBM Java uses {{credType}}. This
> results is the automatic Kerberos login to fail on IBM Java.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2017) Automatic Kerberos login fails on IBM Java
[
https://issues.apache.org/jira/browse/CALCITE-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213375#comment-16213375
]
Josh Elser commented on CALCITE-2017:
-
Per https://github.com/travis-ci/travis-ci/issues/2682, we should actually be
able to get IBM Java 9 (jdk8) builds via travis... Investigating.
> Automatic Kerberos login fails on IBM Java
> --
>
> Key: CALCITE-2017
> URL: https://issues.apache.org/jira/browse/CALCITE-2017
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
>
> Had a report come in from a user.
> Apparently when performing a JAAS login with Krb5LoginModule, Oracle Java
> uses the option {{isInitiator}} whereas IBM Java uses {{credType}}. This
> results is the automatic Kerberos login to fail on IBM Java.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2307) Expose Jetty server metrics via Avatica-server
[ https://issues.apache.org/jira/browse/CALCITE-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471305#comment-16471305 ] Josh Elser commented on CALCITE-2307: - [~karanmehta93] (being lazy) do you have docs you can point me at where you there's info on jetty-jmx? :) > Expose Jetty server metrics via Avatica-server > -- > > Key: CALCITE-2307 > URL: https://issues.apache.org/jira/browse/CALCITE-2307 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Karan Mehta >Priority: Major > > To know how the jetty server is performing, we need to know its metrics. > Eclipse Jetty already provides a way to publish its internal metrics to JMX. > However we need to enable it. This involves adding an additional dependency > on the jetty-jmx project and adding the MBeanContainter in the server beans. > We can customize this via a config parameter if required. > This is essential for PHOENIX-3655 > [~elserj] [~apurtell] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms
[
https://issues.apache.org/jira/browse/CALCITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477443#comment-16477443
]
Josh Elser commented on CALCITE-2294:
-
{quote}Also, the builder method {{withAuthentication}} makes assumptions around
{{loginServiceRealm}} and other parameters which should not be the case. Should
we refactor it as well?
{quote}
What's the assumption you're concerned with? Happy to entertain changes, just
not sure what the issue is.
{quote}The {{HTTPServer}} class provides a static builder class called as
{{Builder}}, however still exposes the constructor as public. This seems
against the builder pattern and breaks expectations. Can I change the
constructors to private?
{quote}
What expectations is it breaking? I'm not seeing a functional difference
between a method {{newBuilder()}} on HttpServer versus the public no-args
constructor on {{Builder}}.
> Allow customization for AvaticaServerConfiguration for plugging new
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Priority: Major
>
> {{AvaticaServerConfiguration}} is currently only created if authentication
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it
> to a builder pattern to create this object and provide a way for users to
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2284) Allow Jetty Server to be customized before startup
[ https://issues.apache.org/jira/browse/CALCITE-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-2284: Affects Version/s: (was: 1.11.0) > Allow Jetty Server to be customized before startup > -- > > Key: CALCITE-2284 > URL: https://issues.apache.org/jira/browse/CALCITE-2284 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Alex Araujo >Assignee: Alex Araujo >Priority: Critical > Fix For: avatica-1.12.0 > > Attachments: CALCITE-2284.patch > > > Avatica server options currently allow users to enable TLS with file based > key stores. In order to support additional options (in memory keystores, > dynamically loaded keys/certificates, etc.) Avatica should provide a callback > to customize the embedded Jetty server before starting it up. > > This would be similar to how Spring Boot allows developers to customize the > embedded server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2284) Allow Jetty Server to be customized before startup
[ https://issues.apache.org/jira/browse/CALCITE-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-2284: --- Assignee: Alex Araujo > Allow Jetty Server to be customized before startup > -- > > Key: CALCITE-2284 > URL: https://issues.apache.org/jira/browse/CALCITE-2284 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Alex Araujo >Assignee: Alex Araujo >Priority: Critical > Fix For: avatica-1.12.0 > > Attachments: CALCITE-2284.patch > > > Avatica server options currently allow users to enable TLS with file based > key stores. In order to support additional options (in memory keystores, > dynamically loaded keys/certificates, etc.) Avatica should provide a callback > to customize the embedded Jetty server before starting it up. > > This would be similar to how Spring Boot allows developers to customize the > embedded server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2284) Allow Jetty Server to be customized before startup
[ https://issues.apache.org/jira/browse/CALCITE-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-2284: Fix Version/s: avatica-1.12.0 > Allow Jetty Server to be customized before startup > -- > > Key: CALCITE-2284 > URL: https://issues.apache.org/jira/browse/CALCITE-2284 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Alex Araujo >Assignee: Alex Araujo >Priority: Critical > Fix For: avatica-1.12.0 > > Attachments: CALCITE-2284.patch > > > Avatica server options currently allow users to enable TLS with file based > key stores. In order to support additional options (in memory keystores, > dynamically loaded keys/certificates, etc.) Avatica should provide a callback > to customize the embedded Jetty server before starting it up. > > This would be similar to how Spring Boot allows developers to customize the > embedded server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2284) Allow Jetty Server to be customized before startup
[ https://issues.apache.org/jira/browse/CALCITE-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-2284. - Resolution: Fixed Fixed in https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=612b80cb2e2dff7913a4d29a252a4c0db28d2095 > Allow Jetty Server to be customized before startup > -- > > Key: CALCITE-2284 > URL: https://issues.apache.org/jira/browse/CALCITE-2284 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Alex Araujo >Assignee: Alex Araujo >Priority: Critical > Fix For: avatica-1.12.0 > > Attachments: CALCITE-2284.patch > > > Avatica server options currently allow users to enable TLS with file based > key stores. In order to support additional options (in memory keystores, > dynamically loaded keys/certificates, etc.) Avatica should provide a callback > to customize the embedded Jetty server before starting it up. > > This would be similar to how Spring Boot allows developers to customize the > embedded server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2318) NumberFormatException while Sqlline start
[
https://issues.apache.org/jira/browse/CALCITE-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-2318.
-
Resolution: Done
> NumberFormatException while Sqlline start
> --
>
> Key: CALCITE-2318
> URL: https://issues.apache.org/jira/browse/CALCITE-2318
> Project: Calcite
> Issue Type: Bug
> Environment: {noformat}
> [serg@localhost ~]$ uname -a
> Linux localhost.localdomain 4.16.7-300.fc28.x86_64 #1 SMP Wed May 2 20:09:13
> UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> [serg@localhost ~]$ infocmp -V
> ncurses 6.1.20180224
> {noformat}
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Minor
>
> Hello
> looks like known issue here https://github.com/jline/jline2/issues/281
> IMHO jline version update will help to have it fixed
> to reproduce just run sqlline
> {noformat}
> [serg@localhost csv]$ ./sqlline
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.get(TerminalFactory.java:186)
> at jline.TerminalFactory.get(TerminalFactory.java:192)
> at sqlline.SqlLineOpts.(SqlLineOpts.java:45)
> at sqlline.SqlLine.(SqlLine.java:54)
> at sqlline.SqlLine.start(SqlLine.java:372)
> at sqlline.SqlLine.main(SqlLine.java:265)
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.create(TerminalFactory.java:51)
> at sqlline.SqlLine.getConsoleReader(SqlLine.java:705)
> at sqlline.SqlLine.begin(SqlLine.java:639)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2352) Upgrade checkstyle to support Java8 lambdas
[ https://issues.apache.org/jira/browse/CALCITE-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-2352: Fix Version/s: avatica-1.12.0 > Upgrade checkstyle to support Java8 lambdas > --- > > Key: CALCITE-2352 > URL: https://issues.apache.org/jira/browse/CALCITE-2352 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Laurent Goujon >Assignee: Laurent Goujon >Priority: Major > Fix For: avatica-1.12.0 > > > Version of checkstyle used by Avatica (5.7) doesn't support constructs from > Java8 like lambdas and static methods in interfaces. > This would result in lots of small changes to adjust to the stricter rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2352) Upgrade checkstyle to support Java8 lambdas
[ https://issues.apache.org/jira/browse/CALCITE-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-2352: --- Assignee: Laurent Goujon > Upgrade checkstyle to support Java8 lambdas > --- > > Key: CALCITE-2352 > URL: https://issues.apache.org/jira/browse/CALCITE-2352 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Laurent Goujon >Assignee: Laurent Goujon >Priority: Major > Fix For: avatica-1.12.0 > > > Version of checkstyle used by Avatica (5.7) doesn't support constructs from > Java8 like lambdas and static methods in interfaces. > This would result in lots of small changes to adjust to the stricter rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2299) TIMESTAMPADD(SQL_TSI_FRAC_SECOND) should be nanoseconds not microseconds
[ https://issues.apache.org/jira/browse/CALCITE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512780#comment-16512780 ] Josh Elser commented on CALCITE-2299: - Any chance we can get some new unit test cases for the new code added? Data types have been notoriously tricky to get right in Avatica :) > TIMESTAMPADD(SQL_TSI_FRAC_SECOND) should be nanoseconds not microseconds > > > Key: CALCITE-2299 > URL: https://issues.apache.org/jira/browse/CALCITE-2299 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.16.0 >Reporter: James Duong >Assignee: Julian Hyde >Priority: Minor > Fix For: avatica-1.12.0 > > > When calling TIMESTAMPADD with the first parameter SQL_TSI_FRAC_SECOND and > the JDBC escape sequence, this gets interpreted as microseconds when it > should be interpreted as nanoseconds. > > From the ODBC spec on MSDN: > [https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/time-date-and-interval-functions?view=sql-server-2017] > 'where fractional seconds are expressed in billionths of a second.' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2299) TIMESTAMPADD(SQL_TSI_FRAC_SECOND) should be nanoseconds not microseconds
[ https://issues.apache.org/jira/browse/CALCITE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512850#comment-16512850 ] Josh Elser commented on CALCITE-2299: - Hi [~Sergey Nuyanzin]. We have lots of tests in Avatica which use HSQLDB for verifying functionality of Avatica functionality outside the context of how Calcite is using it. I'm assuming that we already have some basic testing of TimeUnit – it's good when we can add some kind of test into Avatica itself to try to catch any issues that Calcite would have otherwise uncovered itself (to avoid the back-and-forth of calcite finding avatica bugs and forcing multiple new releases). So, in short, some kind of test that exercises the new NANOSECONDS enum value would be appreciated. > TIMESTAMPADD(SQL_TSI_FRAC_SECOND) should be nanoseconds not microseconds > > > Key: CALCITE-2299 > URL: https://issues.apache.org/jira/browse/CALCITE-2299 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.16.0 >Reporter: James Duong >Assignee: Julian Hyde >Priority: Minor > Fix For: avatica-1.12.0 > > > When calling TIMESTAMPADD with the first parameter SQL_TSI_FRAC_SECOND and > the JDBC escape sequence, this gets interpreted as microseconds when it > should be interpreted as nanoseconds. > > From the ODBC spec on MSDN: > [https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/time-date-and-interval-functions?view=sql-server-2017] > 'where fractional seconds are expressed in billionths of a second.' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-2285.
-
Resolution: Fixed
Fixed in
[https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=97c8a1612220e46fe70fed3a92082e55248f868e]
I did make one change on commit (adding a log4j.properties to
core/src/test/resources) as this was throwing a warning during avatica-core's
unit tests.
Thanks for the very nice path, Karan!
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
