[
https://issues.apache.org/jira/browse/CALCITE-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16596759#comment-16596759
]
ASF GitHub Bot commented on CALCITE-2503:
-----------------------------------------
Github user karanmehta93 commented on the issue:
https://github.com/apache/calcite-avatica/pull/67
@joshelser
> How'd you catch this happening?
Internally, we were running MTLS secured PQS server and trying to connect
and run queries through an MTLS client built on top of calcite-avatica client.
The first trial was run in non-secure mode and second was done in secure mode.
The client was essentially trying to do point gets via phoenix. However it was
doing SSL handshake for every request. A small trial run showed a 10X perf
degradation (This is too generic result though). Upon debugging, I found that
the connection pool uses {Route and State} objects as key, where the state
object is set by DefaultUserTokenHandler class. We need to explicitly set the
same State on the next request so that it can lookup the connection from the
pool. More details here:
https://hc.apache.org/httpcomponents-client-ga/tutorial/html/advanced.html
Its one of the advance use cases for http client lib and I didn't really
expect that to be hit :)
> Any thoughts about how we could test that this doesn't happen in the
future?
I am actually not sure here. I did manual testing to verify that perf
degradation is not happening anymore. Unit tests pass. An IT would be hard to
simulate, I believe. Any advice/suggestions appreciated.
> 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
>
> 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)
