You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Benjamin Reed (JIRA)" <ji...@apache.org> on 2011/06/12 03:49:51 UTC
[jira] [Created] (ZOOKEEPER-1092) get rid of pending changes
get rid of pending changes
--------------------------
Key: ZOOKEEPER-1092
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1092
Project: ZooKeeper
Issue Type: Improvement
Reporter: Benjamin Reed
Priority: Minor
pending changes used by PrepRequestProcessor and FinalRequestProcessor is complicated and requires synchronization between threads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1092) get rid of pending changes
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048237#comment-13048237 ]
Benjamin Reed commented on ZOOKEEPER-1092:
------------------------------------------
just to correct slightly my earlier statement. we do indirectly take advantage of the fact that the datatree contains only committed operations: if the leader tells a follower to truncate, we know that we only need to truncate the log; we don't need to worry about removing anything from the data tree since everything in the tree is committed.
> get rid of pending changes
> --------------------------
>
> Key: ZOOKEEPER-1092
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1092
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Benjamin Reed
> Priority: Minor
>
> pending changes used by PrepRequestProcessor and FinalRequestProcessor is complicated and requires synchronization between threads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1092) get rid of pending changes
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048197#comment-13048197 ]
Benjamin Reed commented on ZOOKEEPER-1092:
------------------------------------------
in reviewing some of the patches lately, i was again bothered by the complexity of outstandingChanges used by PrepRP and FinalRP. Both threads touch that list and prepRP checks both the list and the datatree.
right now datatree has the committed changes, but if we make datatree store the pending changes, then it can be completely maintained by the prepRP. it would also mean that prepRP would execute all operations: both the read and write operations. it turns out that we never take advantage of the fact that datatree contains only committed operations.
in general, i think this would simplify the code, make finalRP go away, allow us to get rid of outstandingChanges and allow us to do all datatree manipulation in the prepRP.
there is a downside: currently order operations as we get them from the clients, which works with the above. we have occasionally talked about letting read operations short circuit the pipeline if there are no writes from the client issuing the read in the pipeline. short circuited requests would go straight to finalRP. if we implement the above, this optimization would be much harder to implement. (i don't see it as much of an issue since we don't have any plans to implement it currently.)
> get rid of pending changes
> --------------------------
>
> Key: ZOOKEEPER-1092
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1092
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Benjamin Reed
> Priority: Minor
>
> pending changes used by PrepRequestProcessor and FinalRequestProcessor is complicated and requires synchronization between threads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira