Hi Colin,
Thanks for the explanation. Yes, I can see the sense in that, although it was
certainly a surprise for me. I’ll just have to be a bit more careful about
instantiating AdminClients in the future.
Cheers,
Michael
> On 13 Aug 2019, at 1:36 am, Colin McCabe wrote:
>
> Hi Michael,
>
>
Hi Michael,
The NetworkClient periodically fetches metadata so that it always knows what
the cluster topology is. This also helps it to have some open connections when
needed to reduce the latency of operations.
To be fair, we haven’t thought very much about optimizing this since the
overhead
Hi Rajini,
I just thought I'd let you know I've sorted through my issue now. It turns out
that I was doing something silly. The SSL handshake errors weren't caused by
the brokers talking to themselves but were instead being initiated from an
AdminClient I had running in a seperate process. Iron
Hi Rajini,
Thanks for the good suggestions. I’ve investigated further and confirmed that
the issue continues to occur even with hostname verification turned off.
I put in the ssl debug option and got some interesting information. I’ve
attached an example of what the logs output when SSL errors s
Hi Michael,
Thanks for the logs.
When keystore is reconfigured in a stable cluster, we wouldn't expect to
see any failures even if there is an issue with the certs since existing
connections continue to work without re-authenticating. When a broker is
restarted, there could be controller re-elect
Hi Michael,
Thank you for reporting this. It is possible that we missed out some
client-side update in KAFKA-8336. Would it be possible for you to provide
logs from multiple brokers around the time of a broker restart when
handshake failures started occurring so that we can try to work out which
c
