On 12/07/2021 18:10, Yuval Paz wrote:
>> Wouldn't it make more sense to set this value to $zkClientTimeout x
> $numServers?
>
> I don't think it would make much sense to calculate it in such a method.
Maybe not, but in the worst case the last ZK server won't be tried
unless the timeout is that long. But sure, having it configurable in
general would be just as good.
> In there they wrote:
>> Note that unlike other configuration stored in ZK, this probably needs to
> be bootstrapped via a System property.
>
> I'm not completely sure why they wrote it, if anyone knows please let me
> know :), apart from this detail it should be pretty straight forward to
> implement this
It seems like the other ZK timeout value (zkClientTimeout) is injected
into CloudConfig using a system property
private int zkClientTimeout = Integer.getInteger("zkClientTimeout",
DEFAULT_ZK_CLIENT_TIMEOUT);
This, in turn, is injected from within the solr script:
CLOUD_MODE_OPTS=("-DzkClientTimeout=$ZK_CLIENT_TIMEOUT")
Which in turn comes from solr.in.(sh|bat):
#ZK_CLIENT_TIMEOUT="15000"
REM set ZK_CLIENT_TIMEOUT=15000
So I'm guessing it makes sense to expose ZK_CLIENT_CONNECT_TIMEOUT in
the same way?
Seems pretty easy to implement. I'll discuss this with $employer, with a
bit of luck you can expect a patch soon.
- Bram
