zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vishal Kathuria (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-1148) Multi-threaded handling of reads
Date Fri, 19 Aug 2011 19:20:29 GMT

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

Vishal Kathuria commented on ZOOKEEPER-1148:

Thanks for taking a look at the patch Patrick. I deliberately did not click "submit patch"
since it was not ready to be committed :)

I will be breaking this up into smaller committable chunks and submitting those patches over
the next few weeks.


> 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
> 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


View raw message