Major Description
This improvement is to take advantage of multiple cores in the machines that typically run ZooKeeper servers to get higher read throughput.
The challenge with multiple threads is read/write ordering guarantees that ZooKeeper provides.
One way of handling these is to let readOnly clients use the multiple threads, and the read/write clients continue to use the same single CommitProcessor thread for both reads and writes. For this to work, a client would have to declare its readOnly intent through a flag at connect time. (We already have a readOnly flag, but its intent is a bit different).
Another way of honoring the read/write guarantee is to let all sessions start as readOnly sessions and have them use the multi-threaded reads until they do their first write. Once a session performs a write, it automatically flips from a read/write session to a read only session and starts using the single threaded CommitProcessor. This is a little tricky as one has to worry about in flight reads when the write comes and we have to make sure those reads finish before the write goes through.
I would like to get the community's feedback on whether it would be useful to have this and whether an automatic discovery of readOnly or read/write intent is critical for this to be useful. For us, the clients know at connect time whether they will ever do a write or not, so an automatic detection is of limited use.