[
https://issues.apache.org/jira/browse/CALCITE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178735#comment-15178735
]
Josh Elser commented on CALCITE-1117:
-------------------------------------
bq. I envisioned Avatica as an API/SPI (kind of like the servlet API). Of
course it comes with an implementation over HTTP
Thinking about this one some more, I can definitely see the worth in trying to
go full-on ServiceLoader for client and server. This would help a bit in
managing the bloat perceived by calcite-core and others. I'd have to give this
some more thought and prototyping to see how it works out. Interesting notion
though...
> Use commons httpclient instead of JDK http client
> -------------------------------------------------
>
> Key: CALCITE-1117
> URL: https://issues.apache.org/jira/browse/CALCITE-1117
> Project: Calcite
> Issue Type: Sub-task
> Components: avatica
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: next
>
>
> I've been stumbling around, trying to get a better understanding of how
> HttpURLConnection works (with http/1.1), applying it to some of the knowledge
> I have with the distributed key-value stores on Hadoop I'm familiar with.
> Along the way, I found lots of recommendations to move to Apache Commons
> HttpClient (http://hc.apache.org) with the broad suggestion that "it's just
> generally better". I mocked this up and was pleasantly surprised to find that
> this netted about a 20% improvement over the existing http client
> implementation (with a stubbed-out JDBC driver inside Avatica -- just
> measuring Avatica itself).
> Thankfully, we have an interface for the http client, so it should be easy to
> add a new implementation with a factory to do some client-side configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
