Multi-threaded handling of reads
---------------------------------
Key: ZOOKEEPER-1148
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1148
Project: ZooKeeper
Issue Type: Improvement
Components: server
Reporter: Vishal Kathuria
Fix For: 3.5.0
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
