[
https://issues.apache.org/jira/browse/CALCITE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177010#comment-15177010
]
Josh Elser commented on CALCITE-1117:
-------------------------------------
bq. Can we justify another dependency? I'd rather that core Avatica keeps its
dependency list VERY short.
Yes. I wouldn't have suggested it otherwise. In this day an age, I really don't
accept a few megabytes as a technical justification for such avoidance. When it
comes down to a +15% performance improvement for ~50 lines of code, it seems
rather silly to me not to do so.
The other typical argument is the worry of dependencies leaking to the client.
There is also no concern here as the classes are shaded+relocated. They will
have no affect on clients.
Is there a reason that I've missed?
> 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)
