Mate Szalay-Beko created ZOOKEEPER-3827:
-------------------------------------------
Summary: configure explicit sessionInitiationTimeout for client
connection
Key: ZOOKEEPER-3827
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3827
Project: ZooKeeper
Issue Type: Improvement
Affects Versions: 3.5.8, 3.6.1
Reporter: Mate Szalay-Beko
Assignee: Mate Szalay-Beko
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
