You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "Mate Szalay-Beko (Jira)" <ji...@apache.org> on 2020/05/12 15:35:00 UTC
[jira] [Updated] (ZOOKEEPER-3827) configure explicit
sessionInitTimeout for client connection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mate Szalay-Beko updated ZOOKEEPER-3827:
----------------------------------------
Description:
Currently the connectTimeout (the maximum amount of time to connect to one ZooKeeper server) in the Java client is initialized as {{<session timeout> / <number of zk servers to connect>}}. See [here|https://github.com/apache/zookeeper/blob/236e3d9183606512f0e03a1f828ad0d392eb6091/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L440] and [here|https://github.com/apache/zookeeper/blob/236e3d9183606512f0e03a1f828ad0d392eb6091/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L1430]). This means, that connecting to a large ZooKeeper cluster can be hard (as we will have shorter connect timeout than we would have by just specifying a single server). The idea behind the current approach (I think) is that the connection initiation should be timeouted when the session timeout elapsed. And we want to make sure that we have the time to try out all the given servers before our sessionTimeout elapses.
But when we use Kerberized cluster with SSL, we might end up having long connection initiation (until all the authentication and handshakes are completed). Still, we might want to keep the session timeout short for our application. E.g. we were facing connection timeouts with Kafka brokers trying to use SASL+SSL to communicate with ZooKeeper.
So it would be nice to be able to set an explicit sessionInitTimeout in the ZooKeeper client, independently from the session timeout.
If this configuration is not set, we would fallback to our current approach. But if it is set, then we would use it to calculate the connectTimeout.
was:
Currently the connectTimeout (the maximum amount of time to connect to one ZooKeeper server) in the Java client is initialized as {{<session timeout> / <number of zk servers to connect>}}. See [here|https://github.com/apache/zookeeper/blob/236e3d9183606512f0e03a1f828ad0d392eb6091/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L440] and [here|https://github.com/apache/zookeeper/blob/236e3d9183606512f0e03a1f828ad0d392eb6091/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L1430]). This means, that connecting to a large ZooKeeper cluster can be hard (as we will have shorter connect timeout than we would have by just specifying a single server). The idea behind the current approach (I think) is that the connection initiation should be timeouted when the session timeout elapsed. And we want to make sure that we have the time to try out all the given servers before our sessionTimeout elapses.
But when we use Kerberized cluster with SSL, we might end up having long connection initiation (until all the authentication and handshakes are completed). Still, we might want to keep the session timeout short for our application. E.g. we were facing connection timeouts with Kafka brokers trying to use SASL+SSL to communicate with ZooKeeper.
So it would be nice to be able to set an explicit sessionInitiationTimeout in the ZooKeeper client, independently from the session timeout.
If this configuration is not set, we would fallback to our current approach. But if it is set, then we would use it to calculate the connectTimeout.
> configure explicit sessionInitTimeout for client connection
> -----------------------------------------------------------
>
> Key: ZOOKEEPER-3827
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3827
> Project: ZooKeeper
> Issue Type: Improvement
> Affects Versions: 3.6.1, 3.5.8
> Reporter: Mate Szalay-Beko
> Assignee: Mate Szalay-Beko
> Priority: Major
>
> Currently the connectTimeout (the maximum amount of time to connect to one ZooKeeper server) in the Java client is initialized as {{<session timeout> / <number of zk servers to connect>}}. See [here|https://github.com/apache/zookeeper/blob/236e3d9183606512f0e03a1f828ad0d392eb6091/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L440] and [here|https://github.com/apache/zookeeper/blob/236e3d9183606512f0e03a1f828ad0d392eb6091/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L1430]). This means, that connecting to a large ZooKeeper cluster can be hard (as we will have shorter connect timeout than we would have by just specifying a single server). The idea behind the current approach (I think) is that the connection initiation should be timeouted when the session timeout elapsed. And we want to make sure that we have the time to try out all the given servers before our sessionTimeout elapses.
> But when we use Kerberized cluster with SSL, we might end up having long connection initiation (until all the authentication and handshakes are completed). Still, we might want to keep the session timeout short for our application. E.g. we were facing connection timeouts with Kafka brokers trying to use SASL+SSL to communicate with ZooKeeper.
> So it would be nice to be able to set an explicit sessionInitTimeout in the ZooKeeper client, independently from the session timeout.
> If this configuration is not set, we would fallback to our current approach. But if it is set, then we would use it to calculate the connectTimeout.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)