[jira] [Commented] (ZOOKEEPER-1148) Multi-threaded handling of reads

["Patrick Hunt (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079698#comment-13079698 ] 

Patrick Hunt commented on ZOOKEEPER-1148:
-----------------------------------------

Hi Vishal, FYI we typically don't consider your patch until you click "submit patch" or otherwise communicate to us that we should provide feedback. Take a look at our "how to contribute" page for more detail: https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Regards.

> 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
>              Labels: scaling
>             Fix For: 3.5.0
>
>         Attachments: zookeeperEverything.patch
>
>
> 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