Thanks Mate for pointing the code out. Exactly what I was looking for.
Although it doesn't look like it has any impact, I will try to do some perf
tests to verify.
Thanks,
Sankalp
On Mon, 6 Jul 2020 at 15:55, Szalay-Bekő Máté
wrote:
> > Should I also be worried about any performance impacts he
> Should I also be worried about any performance impacts here in terms of
CPU/Runtime? Will my Plaintext requests be as fast as they are with a
vanilla Plaintext port? Would be helpful if someone can help me with some
documentation around this.
Using SSL vs using unsecure socket does have some per
Thanks Enrico and Mate for the valuable comments.
Mate, regarding your point- *I don't consider the use of
client.portUnification to be 'bad' or 'unsecure' in itself *
I agree. This is as bad as the case of having a plaintext and TLS port open
at the same time in terms of security.
Should I also
In my opinion you can use port unification during a rolling upgrade of your
ZK cluster and you are moving your servers to TLS.
Another case is that you have to connect to two different ZK clusters, one
with TLS and one with plain connections, some configurations are system
properties so it is hard
Hi Sankalp,
I think it really depends on your security policies. I don't consider the
use of client.portUnification to be 'bad' or 'unsecure' in itself.
Especially, if you can make sure in your cluster that all sensitive data is
protected with ACLs and modified / listed using TLS.
But still the m
Hi Devs,
Can someone share some insights on what is a good use case for the feature
*client.portUnification*? I have a use case where clients would want both
PLAINTEXT and TLS traffic to be served by ZooKeeper server and I want to
avoid exposing and managing 2 different zookeeper ports. Is this a
