Uploaded image for project: 'ZooKeeper'
  1. ZooKeeper
  2. ZOOKEEPER-1148

Multi-threaded handling of reads



    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • server


      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.


        1. zookeeperEverything.patch
          107 kB
          Vishal Kathuria



            Unassigned Unassigned
            vishal.k Vishal Kathuria
            0 Vote for this issue
            0 Start watching this issue