[curator][lock-recipe] pre ZK 3.5 (container nodes), curator lock implementation creates persistent parent node and ephemeral-sequential child node. I believe this is done to mitigate herd-effect. But we have a use-case where 99.99% calls are unique, and we need lock just in case 2 duplicate calls come at the same time. Given that we are still stuck with ZK 3.4 and I want to avoid reaper (since it is deprecated), can I implement a lock recipe which just tries to create ephemeral node without any persistent nodes. Since ZK will fail if node already exists, this will ensure only one call (among the duplicate concurrent calls) will go through ?
Are there any corner cases where it will not work ?
Since I didn't find any library(recipe) with such implementation I was not sure about it.
Can someone please tell me if there is any problem with this approach for the use-case where duplicates are very rare, but whenever it happens we need to make sure only one call goes through?
Hello Team, I am completely new to zookeeper. I am currently going through O'reilley zookeeper book. I have a couple of general question about zookeeper. 1. Is it a good or a Bad idea to expose our zookeeper instance to public with authentication ofcourse? 2.If it is good to expose zookeeper to public, then is it a good idea to have mobile devices connect to the Zookeeper as clients? Any inputs is much appreciated. Thanks.
Actually the more i read, i understood that it is always good to have zookeeper behind a load balancer. And i hope the load balancer can handle authentication. Thanks.
hi I've been having a lot of trouble trying to get a working bcfks keystore for zookeeper TLS ; getting a "DER length more than 4 bytes: 109" error; been debugging for a few hours and nothing quite sticks out
wondering if I missed something obvious here