[
https://issues.apache.org/jira/browse/CALCITE-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16598752#comment-16598752
]
ASF GitHub Bot commented on CALCITE-2503:
-----------------------------------------
Github user joshelser commented on the issue:
https://github.com/apache/calcite-avatica/pull/67
Thanks, @karanmehta93. I just tested using the following and it reproduced
the failure.
```
Java(TM) SE Runtime Environment (build 8.0.5.0 -
pxa6480sr5-20170905_01(SR5))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References
20170901_363591 (JIT enabled, AOT enabled)
```
Hopefully you have a linux box you can use as IBM apparently doesn't
provide JDK builds for OSX x.x
> AvaticaCommonsHttpClientImpl client needs to set user-token on
> HttpClientContext before sending the request
> -----------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-2503
> URL: https://issues.apache.org/jira/browse/CALCITE-2503
> Project: Calcite
> Issue Type: Improvement
> Reporter: Karan Mehta
> Assignee: Karan Mehta
> Priority: Major
> Attachments: CALCITE-2503.001.patch
>
>
> One of the Avatica client implementations, AvaticaCommonsHttpClientImpl, uses
> a PoolingHttpClientConnectionManager. When using mutual authentication on the
> client pool, we need to ensure that we are setting a user-token on the
> HttpClientContext, otherwise it ends up creating a new connection everytime
> and not reusing it. See:
> [https://hc.apache.org/httpcomponents-client-ga/tutorial/html/advanced.html]
> for more details
> This results in significant perf degradation since every new connection tries
> to complete a SSL handshake (which is expensive)
> See:
> https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
