As you mentioned, enabling trace/debug might impact performance.
Here's the approach I'm using now.
-
Parse the Zookeeper transaction logs. The best repo I've found to do
this is https://github.com/alenca/zklogtool. It's feature packed. The
only downside is that it won't record the
Hi ZooKeeper users,
There's an ongoing discussion on the dev list about upgrading the required
Java version to 1.8 on trunk and 3.5 branches.
We'd like to get some feedback from a bigger audience if anybody or any
other component that is dependent on ZooKeeper has any concerns or
objections again
Cool, monitoring the transaction makes much sense I think.
Interesting to see this tool, I didn't know about it yet. For some reason
it replicates most of the logic in FileSnap and FileTxnLog classes, but at
the same time it uses ZooKeeper as a dependency.
Regards,
Andor
On Wed, Mar 7, 2018 at
Hi,
At BookKeeper we are supporting java 8 onwards and we are using 3.5
branch. (Speaking as BookKeeper PMC)
In my company we running all on java8 and we switching to java9, both
clients and servers
So good to see Zookeeper moving to java8
Enrico
Il mer 7 mar 2018, 12:04 Andor Molnar ha scrit
On 3/7/2018 4:04 AM, Andor Molnar wrote:
I've quickly checked some of the major components that are heavy Zk clients:
Hadoop/HDFS = 1.8 required
HBase = 1.8 required
Kafka = 1.7 required (has some 1.8 and 1.9 bindings)
Hive = 1.8 required
Curator = 1.7 required (has 1.8-only async module to take
+1 from me to using Java 8 or even going all the way to 9 for the 3.5
release branch.
On Mar 7, 2018 8:17 AM, "Shawn Heisey" wrote:
> On 3/7/2018 4:04 AM, Andor Molnar wrote:
>
>> I've quickly checked some of the major components that are heavy Zk
>> clients:
>>
>> Hadoop/HDFS = 1.8 required
>>