Zookeeper hard
A system administrator increases `jute.maxbuffer` to 5MB on every ZooKeeper server to store large configuration objects. However, write operations larger than 1MB still fail. What is the most likely cause?
- A The Leader node requires a specialized hardware encryption module to process Znode packets larger than the 1MB default.
- B The ZAB protocol cannot encapsulate broadcast proposals into multiple TCP segments, forcing a hard 1MB limit.
- C The client-side Java system property for `jute.maxbuffer` must also be set to match the server-side configuration.
- D The underlying transaction log filesystem is formatted with a block size that prevents 5MB sequential writes.
Answer: C. The client-side Java system property for `jute.maxbuffer` must also be set to match the server-side configuration.
Jute is the serialization layer. If the client tries to serialize a 5MB packet but its internal safety limit is default (1MB), it throws an exception before even sending the packet.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What is the primary technical function of a ZooKeeper 'Watch'?
- By default, `forceSync` is enabled. If you disable it, what trade-off are you making?
- If the specific ZooKeeper node a client is connected to crashes, what should the client do?
- Which cluster configuration has *worse* availability: A 3-node cluster or a 4-node cluster? (Assuming simple majority quorum)
- According to the CAP Theorem, how is ZooKeeper classified?
- You need to implement a Distributed Queue where multiple producers push tasks. How does the 'Sequential' Znode flag provide the necessary ordering primitive?