[jira] Commented: (ZOOKEEPER-368) Observers

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-368:
-

henry, good to see this. one important benchmark wuld be to see how much does 
the throughput vary with increasing number of observers. Example, we can start 
with an ensemble of 3, with no observers (this performance should be comparable 
to the code without Observers) and then add one observer at a time and see how 
much the throughput varies!


> Observers
> -
>
> Key: ZOOKEEPER-368
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: quorum
>Reporter: Flavio Paiva Junqueira
>Assignee: Henry Robinson
> Attachments: obs-refactor.patch, observer-refactor.patch, 
> observers.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch
>
>
> Currently, all servers of an ensemble participate actively in reaching 
> agreement on the order of ZooKeeper transactions. That is, all followers 
> receive proposals, acknowledge them, and receive commit messages from the 
> leader. A leader issues commit messages once it receives acknowledgments from 
> a quorum of followers. For cross-colo operation, it would be useful to have a 
> third role: observer. Using Paxos terminology, observers are similar to 
> learners. An observer does not participate actively in the agreement step of 
> the atomic broadcast protocol. Instead, it only commits proposals that have 
> been accepted by some quorum of followers.
> One simple solution to implement observers is to have the leader forwarding 
> commit messages not only to followers but also to observers, and have 
> observers applying transactions according to the order followers agreed upon. 
> In the current implementation of the protocol, however, commit messages do 
> not carry their corresponding transaction payload because all servers 
> different from the leader are followers and followers receive such a payload 
> first through a proposal message. Just forwarding commit messages as they 
> currently are to an observer consequently is not sufficient. We have a couple 
> of options:
> 1- Include the transaction payload along in commit messages to observers;
> 2- Send proposals to observers as well.
> Number 2 is simpler to implement because it doesn't require changing the 
> protocol implementation, but it increases traffic slightly. The performance 
> impact due to such an increase might be insignificant, though.
> For scalability purposes, we may consider having followers also forwarding 
> commit messages to observers. With this option, observers can connect to 
> followers, and receive messages from followers. This choice is important to 
> avoid increasing the load on the leader with the number of observers. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-368) Observers

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-368:
-

just to make it more clear, you can start with an ensemble of 3 servers, then 
increase it to 4 (with one observer), then 5 (with 2 observers), 6 (with 3 
observers)  

> Observers
> -
>
> Key: ZOOKEEPER-368
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: quorum
>Reporter: Flavio Paiva Junqueira
>Assignee: Henry Robinson
> Attachments: obs-refactor.patch, observer-refactor.patch, 
> observers.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch
>
>
> Currently, all servers of an ensemble participate actively in reaching 
> agreement on the order of ZooKeeper transactions. That is, all followers 
> receive proposals, acknowledge them, and receive commit messages from the 
> leader. A leader issues commit messages once it receives acknowledgments from 
> a quorum of followers. For cross-colo operation, it would be useful to have a 
> third role: observer. Using Paxos terminology, observers are similar to 
> learners. An observer does not participate actively in the agreement step of 
> the atomic broadcast protocol. Instead, it only commits proposals that have 
> been accepted by some quorum of followers.
> One simple solution to implement observers is to have the leader forwarding 
> commit messages not only to followers but also to observers, and have 
> observers applying transactions according to the order followers agreed upon. 
> In the current implementation of the protocol, however, commit messages do 
> not carry their corresponding transaction payload because all servers 
> different from the leader are followers and followers receive such a payload 
> first through a proposal message. Just forwarding commit messages as they 
> currently are to an observer consequently is not sufficient. We have a couple 
> of options:
> 1- Include the transaction payload along in commit messages to observers;
> 2- Send proposals to observers as well.
> Number 2 is simpler to implement because it doesn't require changing the 
> protocol implementation, but it increases traffic slightly. The performance 
> impact due to such an increase might be insignificant, though.
> For scalability purposes, we may consider having followers also forwarding 
> commit messages to observers. With this option, observers can connect to 
> followers, and receive messages from followers. This choice is important to 
> avoid increasing the load on the leader with the number of observers. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-368) Observers

[Henry Robinson (JIRA)]

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

Henry Robinson commented on ZOOKEEPER-368:
--

Just to update: I'm putting the patch through some tests and micro-benchmarks 
here and hope to offer a new patch very soon. The results are so far 
encouraging:

Created 1 nodes in 17.1312019825 seconds, at 583.730202365 requests/second 
(without Observers)
Created 1 nodes in 9.63481593132 seconds, at 1037.90254752 requests/second 
(with Observers)

This is a 7-node ensemble, in the first instance it's homogeneously Followers, 
in the second 4 Observers and 3 Followers. As expected, performance is 
seriously better than the homogeneous case. 



> Observers
> -
>
> Key: ZOOKEEPER-368
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: quorum
>Reporter: Flavio Paiva Junqueira
>Assignee: Henry Robinson
> Attachments: obs-refactor.patch, observer-refactor.patch, 
> observers.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch
>
>
> Currently, all servers of an ensemble participate actively in reaching 
> agreement on the order of ZooKeeper transactions. That is, all followers 
> receive proposals, acknowledge them, and receive commit messages from the 
> leader. A leader issues commit messages once it receives acknowledgments from 
> a quorum of followers. For cross-colo operation, it would be useful to have a 
> third role: observer. Using Paxos terminology, observers are similar to 
> learners. An observer does not participate actively in the agreement step of 
> the atomic broadcast protocol. Instead, it only commits proposals that have 
> been accepted by some quorum of followers.
> One simple solution to implement observers is to have the leader forwarding 
> commit messages not only to followers but also to observers, and have 
> observers applying transactions according to the order followers agreed upon. 
> In the current implementation of the protocol, however, commit messages do 
> not carry their corresponding transaction payload because all servers 
> different from the leader are followers and followers receive such a payload 
> first through a proposal message. Just forwarding commit messages as they 
> currently are to an observer consequently is not sufficient. We have a couple 
> of options:
> 1- Include the transaction payload along in commit messages to observers;
> 2- Send proposals to observers as well.
> Number 2 is simpler to implement because it doesn't require changing the 
> protocol implementation, but it increases traffic slightly. The performance 
> impact due to such an increase might be insignificant, though.
> For scalability purposes, we may consider having followers also forwarding 
> commit messages to observers. With this option, observers can connect to 
> followers, and receive messages from followers. This choice is important to 
> avoid increasing the load on the leader with the number of observers. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-550) Java Queue Recipe

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-550:
-

bq. 1) Updated the README.txt

are you sure you update the README? I could not find the content on 
ZCONNECTIONLOSS

bq. 4) The current patch takes in an acl, I mostly copied this handling from 
the lock recipe, is there more handling I should add?

that should be fine!

> Java Queue Recipe
> -
>
> Key: ZOOKEEPER-550
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-550
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: java client
>Affects Versions: 3.2.1
>Reporter: Steven Cheng
>Assignee: Steven Cheng
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-550.patch, ZOOKEEPER-550.patch, 
> ZOOKEEPER-550.patch
>
>
> This patch adds a recipe for creating a distributed queue with ZooKeeper 
> similar to the WriteLock recipe and some sequential tests.  This early 
> attempt follows the Java BlockingQueue interface, though it doesn't implement 
> it since I don't think there's a good reason for it to be Iterable.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-549) Refactor Followers and related classes into a Peer->Follower hierarchy in preparation for Observers

[Henry Robinson (JIRA)]

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

Henry Robinson commented on ZOOKEEPER-549:
--

Mahadev / Flavio -  

Thanks for the comments!

I agree about renaming from Peer; Learner isn't a bad name. If no-one has a 
better suggestion, I'll do that :)

Good point on the downcasts, I'll remove the unnecessary ones. Also good catch 
on the imports; I rely on Eclipse to catch them and it sometimes doesn't. 

Definitely agree on the testing; but since this is a rearrangement of code it's 
not clear how to write many more functional tests since we already have some 
coverage. Is anyone running a stress test workload? I've just got my hands on 
some resources to do something similar, but setting it up would take a bit of 
time. 

I think there are a host of refactorings that could still stand to be done on 
this code and elsewhere. I agree on the package split, that probably belongs in 
this JIRA.






> Refactor Followers and related classes into a Peer->Follower hierarchy in 
> preparation for Observers
> ---
>
> Key: ZOOKEEPER-549
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-549
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: quorum, server
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Assignee: Henry Robinson
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-549.patch, ZOOKEEPER-549.patch
>
>
> For the Observers patch (ZOOKEEPER-368), a lot of functionality is shared 
> between Followers and Observers. To avoid copying code, it makes sense to 
> push the common code into a parent Peer class and specialise it for Followers 
> and Observers. At the same time, some of the lengthier methods in Follower 
> can be broken up to make the code more readable. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-550) Java Queue Recipe

[Steven Cheng (JIRA)]

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

Steven Cheng commented on ZOOKEEPER-550:


Thank you for the feedback Mahadev:

1) Updated the README.txt

2) I'll revise it to make it more clear.

3) A return is done after the delete in remove() and take(), only the client 
that deletes the node can return the data, all others will get a 
NoNodeException.  If different exception is thrown then it will exit the 
method.  

The loop can only continue if NoNodeExceptions are thrown, these are only 
thrown when another client has remove()d or take()n the node.

4) The current patch takes in an acl, I mostly copied this handling from the 
lock recipe, is there more handling I should add?

I would like to integrate more of the common pieces of the lock recipe into the 
queue but I think I will leave this to later.


> Java Queue Recipe
> -
>
> Key: ZOOKEEPER-550
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-550
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: java client
>Affects Versions: 3.2.1
>Reporter: Steven Cheng
>Assignee: Steven Cheng
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-550.patch, ZOOKEEPER-550.patch, 
> ZOOKEEPER-550.patch
>
>
> This patch adds a recipe for creating a distributed queue with ZooKeeper 
> similar to the WriteLock recipe and some sequential tests.  This early 
> attempt follows the Java BlockingQueue interface, though it doesn't implement 
> it since I don't think there's a good reason for it to be Iterable.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-549) Refactor Followers and related classes into a Peer->Follower hierarchy in preparation for Observers

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-549:
-

henry,
 good to see this. This is much needed refactoring. Some comments/questions-

 - +1 on flavio's suggestion. I couldnt find a better name then Peer though :). 
We do have to keep the Followers as Followers because that we use for the ones 
that have a say in the proposals!

 - there is an unwanted import in Follower.java and more in other classes like 
FollowerZooKeepeerServer and maybe others.
  {code}
  import org.apache.zookeeper.txn.TxnHeader;
  {code}

- downcast operations in Follower.java for downcasting to 
FollowerZooKeeperServer. Its done on each and every read of packet and 
processing. There is some cost to it.

  {quote}
  Downcast operations (also called narrowing conversions in the Java Language 
Specification) convert an ancestor class reference to a subclass reference. 
This casting operation creates execution overhead, since Java requires that the 
cast be checked at runtime to make sure that it's valid.
 {quote}
 from javaworld.
 I think you should be able to downcast once and use that object from then on?

-  other then that, we might want to consider refactoring all the classes into 
subpackages like flavio suggested

- also, we should make sure we do enough testing because this is a lot of 
refactoring.


> Refactor Followers and related classes into a Peer->Follower hierarchy in 
> preparation for Observers
> ---
>
> Key: ZOOKEEPER-549
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-549
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: quorum, server
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Assignee: Henry Robinson
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-549.patch, ZOOKEEPER-549.patch
>
>
> For the Observers patch (ZOOKEEPER-368), a lot of functionality is shared 
> between Followers and Observers. To avoid copying code, it makes sense to 
> push the common code into a parent Peer class and specialise it for Followers 
> and Observers. At the same time, some of the lengthier methods in Follower 
> can be broken up to make the code more readable. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Erik Holstad (JIRA)]

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

Erik Holstad commented on ZOOKEEPER-472:


@ Mahadev, no reason for it, just a part of the mess with me using another 
indention scheme for the original patch.

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch, 
> zookeeper-472.patch, zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Erik Holstad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Holstad updated ZOOKEEPER-472:
---

Attachment: zookeeper-472.patch

Fixed headers

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch, 
> zookeeper-472.patch, zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-472:
-

erik, there are apache header changes in 2 files, any reason for that? 

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch, 
> zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Erik Holstad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Holstad updated ZOOKEEPER-472:
---

Attachment: zookeeper-472.patch

Fixed compile error.

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch, 
> zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Erik Holstad (JIRA)]

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

Erik Holstad commented on ZOOKEEPER-472:


@ Mahadev, yeah that was my bad. Not sure why my environment didn't show that 
as an error. 

Erik

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch, 
> zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-552) add performance benchmark/docs for synchronous operations

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-552:
-

are we measuring latencies or the throughput with certain number of clients?

> add performance benchmark/docs for synchronous operations
> -
>
> Key: ZOOKEEPER-552
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-552
> Project: Zookeeper
>  Issue Type: Task
>  Components: c client, java client, server
>Reporter: Patrick Hunt
> Fix For: 3.3.0
>
>
> we currently benchmark async operations, but not sync. it would be good to 
> benchmark sync operations so that users
> know what to expect/tradeoffs.
> Also, afaik we currently only benchmark java client - we should benchmark the 
> c client as well (if only to ensure perf is comperable)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-555) Add stat information to GetChildrenResponse

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-555:
-

agreed. I do think the Stat information with getChidren info provides more and 
useful information which can be used for total ordering of getChildren requests!

> Add stat information to GetChildrenResponse
> ---
>
> Key: ZOOKEEPER-555
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-555
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: c client, contrib-bindings, java client, server
>Affects Versions: 3.3.0
>Reporter: Árni Már Jónsson
>Assignee: Árni Már Jónsson
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: getchildren_stat.patch
>
>
> GetChildren() is the only non-create/delete API which does not include the 
> node stat information. I propose that the definition of GetChildren() should 
> be:
> class GetChildrenResponse {
> vector children;
> org.apache.zookeeper.data.Stat stat;
> }
> There is a trivial fix to the server (FinalRequestProcessor.java): rsp = new 
> GetChildrenResponse(children, stat);
> And something similar to the  client library.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-472:
-

erik,
 I just tried compiling the code with ant jar and it fails to compile with the 
folowing error -

{code}
compile:
[javac] Compiling 104 source files to 
/home/mahadev/workspace/zookeeper-commit-trunk/build/classes
[javac] 
/home/mahadev/workspace/zookeeper-commit-trunk/src/java/main/org/apache/zookeeper/server/DataTree.java:1055:
 children has private access in org.apache.zookeeper.server.DataNode
[javac] node.parent.children.add(path.substring(lastSlash + 
1));
[javac]^
[javac] 1 error
{code}

I havent ahd a chance to review the code yet, but I couldnt help but notice 
changes to license headers on 
src/java/main/org/apache/zookeeper/server/DataNode.java. Is there something you 
changed in the licence?



> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Erik Holstad (JIRA)]

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

Erik Holstad commented on ZOOKEEPER-472:


@ Patrik, sorry for not doing this yesterday, had some other stuff that I 
needed to take care of.  Yeah, that patch was created against an older branch, 
but I updated to trunk
in Eclipse and tested it before submitting it, but there seems to have been 
some issues with that.
This patch applied clean on trunk as of this morning using regular patch -p0

Erik

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Erik Holstad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Holstad updated ZOOKEEPER-472:
---

Attachment: zookeeper-472.patch

Fixed issues, so that patch applies to trunk

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-472) Making DataNode not instantiate a HashMap when the node is ephmeral

[Erik Holstad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Holstad updated ZOOKEEPER-472:
---

Attachment: (was: zookeeper-472-v2.patch)

> Making DataNode not instantiate a HashMap when the node is ephmeral
> ---
>
> Key: ZOOKEEPER-472
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-472
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.1, 3.2.0
>Reporter: Erik Holstad
>Assignee: Erik Holstad
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: zookeeper-472.patch, zookeeper-472.patch
>
>
> Looking at the code, there is an overhead of a HashSet object for that nodes 
> children, even though the node might be an ephmeral node and cannot have 
> children.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hudson build is back to normal: ZooKeeper-trunk #499

[Apache Hudson Server]

See