question hive.server2.thrift.http.cookie.auth.enabled in Support Questions

hive.server2.thrift.http.cookie.auth.enabled

AdityaShaw — Wed, 29 Jul 2020 10:28:39 GMT

Hi Team,

We are hitting a bug BUG-77340 where HS2 failover requires knox restart if cookie use is enabled for HS2. We checked https://my.cloudera.com/knowledge/quotError-opening?id=273455 and it is mentioned to set hive.server2.thrift.http.cookie.auth.enabled to false. We would like to know if there is any known performance impact if we set this parameter to false.

Also, we have below parameters set to 600s but still we are seeing server 500 error.

gateway.httpclient.connectionTimeout 600s gateway.httpclient.socketTimeout 600s

Re: hive.server2.thrift.http.cookie.auth.enabled

Bender — Wed, 29 Jul 2020 11:49:35 GMT

Hello @AdityaShaw ,

thank you for inquiring about the performance impact on disabling hive.server2.thrift.http.cookie.auth.enabled.

I have done some research in our internal jira and support cases, however have not seen any performance issue reported.

Please note, this bug is now fixed as part of HIVE-22841 and will be available in a future HDP release.

Thank you:
Ferenc

Re: hive.server2.thrift.http.cookie.auth.enabled

AdityaShaw — Wed, 29 Jul 2020 17:38:25 GMT

Hello @Bender

Thanks a lot for your response. Can you please also provide some insight on timeout parameter. Can this be increased and will there be any extra load on Knox if we increase the timeout and maxConnections

Re: hive.server2.thrift.http.cookie.auth.enabled

Bender — Thu, 30 Jul 2020 08:36:16 GMT

Hello @AdityaShaw ,

sorry I have missed addressing your enquiry about the server 500 error. Based on the KB article you referenced, it is related to the bug. Do you still have the server 500 error once hive.server2.thrift.http.cookie.auth.enabled is set to false, please?

Should you experience disconnects even after applying the workaround, you might have too many HTTPClient connections, which are too high for KNOX to handle at a time.

Please only change any of the parameters listed below once you tested that the above workaround was not sufficient. Based on my research the below parameters are still safe to apply. Before applying any changes in production, please test out the new values in a non-prod environment, as we are not familiar with your use cases and how your cluster/workload is designed:

gateway.httpclient.connectionTimeout=600000 (10 min)
gateway.httpclient.socketTimeout=600000 (10 min)
gateway.metrics.enabled=false
gateway.jmx.metrics.reporting.enabled=false
gateway.httpclient.maxConnections=128

Kind regards:

Ferenc