[jira] Commented: (ZOOKEEPER-706) large numbers of watches can cause session re-establishment to fail

[Patrick Hunt (JIRA)]

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

Patrick Hunt commented on ZOOKEEPER-706:


This is a pretty easy one for someone to fix, and as more users use more 
watches it would be good to get this addressed.

> large numbers of watches can cause session re-establishment to fail
> ---
>
> Key: ZOOKEEPER-706
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-706
> Project: Zookeeper
>  Issue Type: Bug
>  Components: c client, java client
>Affects Versions: 3.1.2, 3.2.2, 3.3.0
>Reporter: Patrick Hunt
>Priority: Critical
> Fix For: 3.4.0
>
>
> If a client sets a large number of watches the "set watches" operation during 
> session re-establishment can fail.
> for example:
>  WARN  [NIOServerCxn.Factory:22801:nioserverc...@417] - Exception causing 
> close of session 0xe727001201a4ee7c due to java.io.IOException: Len error 
> 4348380
> in this case the client was a web monitoring app and had set both data and 
> child watches on > 32k znodes.
> there are two issues I see here we need to fix:
> 1) handle this case properly (split up the set watches into multiple calls I 
> guess...)
> 2) the session should have expired after the "timeout". however we seem to 
> consider any message from the client as re-setting the expiration on the 
> server side. Probably we should only consider messages from the client that 
> are sent during an established session, otherwise we can see this situation 
> where the session is not established however the session is not expired 
> either. Perhaps we should create another JIRA for this particular issue.

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

Review Request: ZOOKEEPER-912: Lower log levels in ZK client for trace/debug messages.

[Patrick Hunt]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7/
---

Review request for zookeeper.


Summary (updated)
---

Lower log levels in ZK client for trace/debug messages.


This addresses bug ZOOKEEPER-912.
https://issues.apache.org/jira/browse/ZOOKEEPER-912


Diffs
-

  /src/java/main/org/apache/zookeeper/ClientCnxn.java 1027676 
  /src/java/main/org/apache/zookeeper/Environment.java 1027676 
  /src/java/main/org/apache/zookeeper/ZooKeeper.java 1027676 

Diff: https://reviews.apache.org/r/7/diff


Testing
---

Manual functional testing.


Thanks,

Anthony

[jira] Updated: (ZOOKEEPER-904) super digest is not actually acting as a full superuser

[Mahadev konar (JIRA)]

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

Mahadev konar updated ZOOKEEPER-904:


  Resolution: Fixed
Hadoop Flags: [Reviewed]
  Status: Resolved  (was: Patch Available)

> super digest is not actually acting as a full superuser
> ---
>
> Key: ZOOKEEPER-904
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-904
> Project: Zookeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.3.1
>Reporter: Camille Fournier
>Assignee: Camille Fournier
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-904-332.patch, ZOOKEEPER-904.patch
>
>
> The documentation states:
> New in 3.2:  Enables a ZooKeeper ensemble administrator to access the znode 
> hierarchy as a "super" user. In particular no ACL checking occurs for a user 
> authenticated as super.
> However, if a super user does something like:
> zk.setACL("/", Ids.READ_ACL_UNSAFE, -1);
> the super user is now bound by read-only ACL. This is not what I would expect 
> to see given the documentation. It can be fixed by moving the chec for the 
> "super" authId in PrepRequestProcessor.checkACL to before the for(ACL a : 
> acl) loop.

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

[jira] Commented: (ZOOKEEPER-904) super digest is not actually acting as a full superuser

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-904:
-

Ran the tests, it passes. I just committed this to 3.3 and trunk.

thanks Camille.

> super digest is not actually acting as a full superuser
> ---
>
> Key: ZOOKEEPER-904
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-904
> Project: Zookeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.3.1
>Reporter: Camille Fournier
>Assignee: Camille Fournier
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-904-332.patch, ZOOKEEPER-904.patch
>
>
> The documentation states:
> New in 3.2:  Enables a ZooKeeper ensemble administrator to access the znode 
> hierarchy as a "super" user. In particular no ACL checking occurs for a user 
> authenticated as super.
> However, if a super user does something like:
> zk.setACL("/", Ids.READ_ACL_UNSAFE, -1);
> the super user is now bound by read-only ACL. This is not what I would expect 
> to see given the documentation. It can be fixed by moving the chec for the 
> "super" authId in PrepRequestProcessor.checkACL to before the for(ACL a : 
> acl) loop.

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

Review Request: This is a test review, it doesnt say much

[gavin]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9/
---

Review request for zookeeper.


Summary
---

test review, please ignore


Diffs
-


Diff: https://reviews.apache.org/r/9/diff


Testing
---

I said ignore! what you still doing here?


Thanks,

admin

Re: Review Request: testing rb please ignore

[gavin]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8/
---

(Updated 2010-10-26 15:01:35.042001)


Review request for zookeeper.


Changes
---

testing rb


Summary
---

testing RB, please ignore


Diffs
-

  /src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 1026388 
  /src/java/test/org/apache/zookeeper/test/AuthTest.java 1026388 

Diff: https://reviews.apache.org/r/8/diff


Testing (updated)
---

no tests


Thanks,

Patrick

Re: Review Request: testing rb please ignore

[gavin]

> On 2010-10-26 14:09:52, Patrick Hunt wrote:
> > test review comment

test comment, lemme know if you get it!


- admin


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8/#review3
---


On 2010-10-26 14:06:42, Patrick Hunt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/8/
> ---
> 
> (Updated 2010-10-26 14:06:42)
> 
> 
> Review request for zookeeper.
> 
> 
> Summary
> ---
> 
> testing RB, please ignore
> 
> 
> Diffs
> -
> 
>   /src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 
> 1026388 
>   /src/java/test/org/apache/zookeeper/test/AuthTest.java 1026388 
> 
> Diff: https://reviews.apache.org/r/8/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Patrick
> 
>

[jira] Commented: (ZOOKEEPER-851) ZK lets any node to become an observer

[Vishal K (JIRA)]

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

Vishal K commented on ZOOKEEPER-851:


going once, going twice ... :)

> ZK lets any node to become an observer
> --
>
> Key: ZOOKEEPER-851
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851
> Project: Zookeeper
>  Issue Type: Bug
>  Components: quorum, server
>Affects Versions: 3.3.1
>Reporter: Vishal K
>Priority: Critical
> Fix For: 3.4.0
>
>
> I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as 
> show below:
> tickTime=2000
> dataDir=/var/zookeeper
> clientPort=2181
> initLimit=5
> syncLimit=2
> server.0=10.150.27.61:2888:3888
> server.1=10.150.27.62:2888:3888
> server.2=10.150.27.63:2888:3888
> I wanted to add another node to the cluster. In fourth node's zoo.cfg, I 
> created another entry for that node and started zk server. The zoo.cfg on the 
> first 3 nodes was left unchanged. The fourth node was able to join the 
> cluster even though the 3 nodes had no idea about the fourth node.
> zoo.cfg on fourth node:
> tickTime=2000
> dataDir=/var/zookeeper
> clientPort=2181
> initLimit=5
> syncLimit=2
> server.0=10.150.27.61:2888:3888
> server.1=10.150.27.62:2888:3888
> server.2=10.150.27.63:2888:3888
> server.3=10.17.117.71:2888:3888
> It looks like 10.17.117.71 is becoming an observer in this case. I was 
> expecting that the leader will reject 10.17.117.71.
> # telnet 10.17.117.71 2181
> Trying 10.17.117.71...
> Connected to 10.17.117.71.
> Escape character is '^]'.
> stat
> Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT
> Clients:
>  /10.17.117.71:37297[1](queued=0,recved=1,sent=0)
> Latency min/avg/max: 0/0/0
> Received: 3
> Sent: 2
> Outstanding: 0
> Zxid: 0x20065
> Mode: follower
> Node count: 288

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

Re: New strategy for Netty (ZOOKEEPER-823) was: What's the QA strategy of ZooKeeper?

[Mahadev Konar]

This sounds great.
Thanks
mahadev


On 10/16/10 1:56 AM, "Thomas Koch"  wrote:

> Benjamin Reed:
>>   actually, the other way of doing the netty patch (since i'm scared of
>> merges) would be to do a refactor cleanup patch with an eye toward
>> netty, and then another patch to actually add netty. [...]
> Hi Benjamin,
> 
> I've had exactly the same thought last evening. Instead of trying to find the
> bug(s) in the current patch, I'd like to start it over again and do small
> incremental changes from the current trunk towards the current ZOOKEEPER-823
> patch.
> Maybe I could do this in ZOOKEEPER-823 patch, this would mean to revert the
> already applied ZOOKEEPER-823 patch.
> Then I want to test each incremental step at least 5 times to find the step(s)
> that breaks ZK.
> This approach should take me another two weeks, I believe, mostly because each
> Test run takes ~15-25 minutes.
> 
> Cheers,
> 
> Thomas Koch, http://www.koch.ro
> 

[jira] Commented: (ZOOKEEPER-87) Follower does not shut itself down if its too far behind the leader.

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-87:


exactly vishal. The problem is to avoid clients being connected to a server 
which can lag behind the leader. 

> Follower does not shut itself down if its too far behind the leader.
> 
>
> Key: ZOOKEEPER-87
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-87
> Project: Zookeeper
>  Issue Type: Bug
>  Components: quorum
>Reporter: Mahadev konar
>Assignee: Mahadev konar
>Priority: Critical
> Fix For: 3.4.0
>
>
> Currently, the follower if lagging behind keeps sending pings to the leader 
> it will stay alive and will keep getting further and further behind the 
> leader. The follower should shut itself down if it is not able to keep up to 
> the leader within some limit so that gurantee of updates can be made to the 
> clients connected to different servers.

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

Re: Apache now has reviewboard

[Patrick Hunt]

FYI apache infra is working on things like email notifications and such
(partially works). For the time being update the JIRA with a link if you
create a RB request or comment.

We should think about what we want to do going forward. For example changing
zk's "how to contribute" to reflect new dev workflow requirements.

Patrick

On Tue, Oct 26, 2010 at 2:41 PM, Mahadev Konar wrote:

> That¹s really nice.
>
> mahadev
>
>
> On 10/25/10 10:16 PM, "Patrick Hunt"  wrote:
>
> > FYI:
> > https://blogs.apache.org/infra/entry/reviewboard_instance_running_at_the
> >
> > We should start using this, I've used it for other projects and it worked
> > out quite well.
> >
> > Patrick
> >
>
>

Re: Apache now has reviewboard

[Mahadev Konar]

That¹s really nice.

mahadev


On 10/25/10 10:16 PM, "Patrick Hunt"  wrote:

> FYI:
> https://blogs.apache.org/infra/entry/reviewboard_instance_running_at_the
> 
> We should start using this, I've used it for other projects and it worked
> out quite well.
> 
> Patrick
> 

[jira] Commented: (ZOOKEEPER-912) ZooKeeper client logs trace and debug messages at level INFO

[Patrick Hunt (JIRA)]

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

Patrick Hunt commented on ZOOKEEPER-912:


I have issues with this patch that I detailed on https://reviews.apache.org/r/7/

In particular I think you can get the same effect through log4j.properties 
configuration. (details in my review feedback).

I'm -1 for making these changes. What do other people think, agree/disagree?

> ZooKeeper client logs trace and debug messages at level INFO
> 
>
> Key: ZOOKEEPER-912
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-912
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: java client
>Affects Versions: 3.3.1
>Reporter: Anthony Urso
>Assignee: Anthony Urso
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: zk-loglevel.patch
>
>
> ZK logs a lot of uninformative trace and debug messages to level INFO.  This 
> fuzzes up everything and makes it easy to miss useful log info. 

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

Re: Review Request: Lower log levels in ZK client for trace/debug messages.

[Patrick Hunt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.apache.org/r/7/#review2
---


Most of the messages you changed are things we rely on to post-mortem issues. 
Many of these logs were added based on experiences running production systems 
and helping users (and admins) identify what's going on in a running system. 
Generally these are only output when something significant changes 
(conn/session est/close) and are therefore not seen frequently.

Alternately (vs this patch) I think you should look at configuring your log4j 
configuration in log4j.properties. You can pretty much get what you want (turn 
off info messages) by either setting the appender threshold to "WARN" or by 
setting the threshold on a per-class basis.

See: http://logging.apache.org/log4j/1.2/manual.html specifically:

# Print only messages of level WARN or above in the package com.foo.
log4j.logger.com.foo=WARN

You can set this parameter for a specific class, such as 
log4j.logger.org.apache.zookeeper.ZooKeeper (etc...)



/src/java/main/org/apache/zookeeper/ClientCnxn.java


This is very useful to see in some cases. (however not as critical as some 
of the other changes I've highlighted, and it should def not be trace).

There have definitely been some cases in production systems where all you 
have is an INFO level log that this has helped to debug. I'd be hesitant to 
remove this, esp given it's typically only output when the client is shut down.



/src/java/main/org/apache/zookeeper/ClientCnxn.java


This is a critical message, it should not be changed.



/src/java/main/org/apache/zookeeper/ClientCnxn.java


similar to line 744.

Connection establishment and session establishment are two critical 
messages for understanding client state.



/src/java/main/org/apache/zookeeper/ClientCnxn.java


Nice to know this if/when clients are unable to connect to the server. At 
least you know they are trying.



/src/java/main/org/apache/zookeeper/ClientCnxn.java


again not as critical, but very useful in production env.



/src/java/main/org/apache/zookeeper/Environment.java


Not a good idea. This is critical for debugging issues.



/src/java/main/org/apache/zookeeper/ZooKeeper.java


this is important for verifying that the user is establishing the 
connection, it's only output at session creation time. I wouldn't remove it 
(actually it was added/improved based on user feedback).



/src/java/main/org/apache/zookeeper/ZooKeeper.java


same here



/src/java/main/org/apache/zookeeper/ZooKeeper.java


ditto


- Patrick


On None, Anthony Urso wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.apache.org/r/7/
> ---
> 
> Review request for zookeeper.
> 
> 
> Summary
> ---
> 
> Lower log levels in ZK client for trace/debug messages.
> 
> 
> Diffs
> -
> 
>   /src/java/main/org/apache/zookeeper/ClientCnxn.java 1027676 
>   /src/java/main/org/apache/zookeeper/Environment.java 1027676 
>   /src/java/main/org/apache/zookeeper/ZooKeeper.java 1027676 
> 
> Diff: http://reviews.apache.org/r/7/diff
> 
> 
> Testing
> ---
> 
> Manual functional testing.
> 
> 
> Thanks,
> 
> Anthony
> 
>

[jira] Commented: (ZOOKEEPER-904) super digest is not actually acting as a full superuser

[Mahadev konar (JIRA)]

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

Mahadev konar commented on ZOOKEEPER-904:
-

good catch. +1 for the patch.  Ill run ant test and will commit to both 3.3.2 
and 3.4.



> super digest is not actually acting as a full superuser
> ---
>
> Key: ZOOKEEPER-904
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-904
> Project: Zookeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.3.1
>Reporter: Camille Fournier
>Assignee: Camille Fournier
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-904-332.patch, ZOOKEEPER-904.patch
>
>
> The documentation states:
> New in 3.2:  Enables a ZooKeeper ensemble administrator to access the znode 
> hierarchy as a "super" user. In particular no ACL checking occurs for a user 
> authenticated as super.
> However, if a super user does something like:
> zk.setACL("/", Ids.READ_ACL_UNSAFE, -1);
> the super user is now bound by read-only ACL. This is not what I would expect 
> to see given the documentation. It can be fixed by moving the chec for the 
> "super" authId in PrepRequestProcessor.checkACL to before the for(ACL a : 
> acl) loop.

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

[jira] Updated: (ZOOKEEPER-702) GSoC 2010: Failure Detector Model

[Mahadev konar (JIRA)]

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

Mahadev konar updated ZOOKEEPER-702:


Fix Version/s: 3.4.0

> GSoC 2010: Failure Detector Model
> -
>
> Key: ZOOKEEPER-702
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-702
> Project: Zookeeper
>  Issue Type: Wish
>Reporter: Henry Robinson
>Assignee: Abmar Barros
> Fix For: 3.4.0
>
> Attachments: bertier-pseudo.txt, bertier-pseudo.txt, chen-pseudo.txt, 
> chen-pseudo.txt, phiaccrual-pseudo.txt, phiaccrual-pseudo.txt, 
> ZOOKEEPER-702-code.patch, ZOOKEEPER-702-doc.patch, ZOOKEEPER-702.patch, 
> ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, 
> ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, 
> ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, 
> ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, 
> ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch
>
>
> Failure Detector Module
> Possible Mentor
> Henry Robinson (henry at apache dot org)
> Requirements
> Java, some distributed systems knowledge, comfort implementing distributed 
> systems protocols
> Description
> ZooKeeper servers detects the failure of other servers and clients by 
> counting the number of 'ticks' for which it doesn't get a heartbeat from 
> other machines. This is the 'timeout' method of failure detection and works 
> very well; however it is possible that it is too aggressive and not easily 
> tuned for some more unusual ZooKeeper installations (such as in a wide-area 
> network, or even in a mobile ad-hoc network).
> This project would abstract the notion of failure detection to a dedicated 
> Java module, and implement several failure detectors to compare and contrast 
> their appropriateness for ZooKeeper. For example, Apache Cassandra uses a 
> phi-accrual failure detector (http://ddsg.jaist.ac.jp/pub/HDY+04.pdf) which 
> is much more tunable and has some very interesting properties. This is a 
> great project if you are interested in distributed algorithms, or want to 
> help re-factor some of ZooKeeper's internal code.

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

[jira] Updated: (ZOOKEEPER-882) Startup loads last transaction from snapshot

[Mahadev konar (JIRA)]

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

Mahadev konar updated ZOOKEEPER-882:


Fix Version/s: 3.4.0

> Startup loads last transaction from snapshot
> 
>
> Key: ZOOKEEPER-882
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-882
> Project: Zookeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Jared Cantwell
>Assignee: Jared Cantwell
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: 882.diff, restore, ZOOKEEPER-882.patch
>
>
> On startup, the server first loads the latest snapshot, and then loads from 
> the log starting at the last transaction in the snapshot.  It should begin 
> from one past that last transaction in the log.  I will attach a possible 
> patch.

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

[jira] Updated: (ZOOKEEPER-907) Spurious "KeeperErrorCode = Session moved" messages

[Mahadev konar (JIRA)]

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

Mahadev konar updated ZOOKEEPER-907:


Status: Patch Available  (was: Open)

> Spurious "KeeperErrorCode = Session moved" messages
> ---
>
> Key: ZOOKEEPER-907
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-907
> Project: Zookeeper
>  Issue Type: Bug
>Affects Versions: 3.3.1
>Reporter: Vishal K
>Assignee: Vishal K
>Priority: Blocker
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-907.patch, ZOOKEEPER-907.patch_v2
>
>
> The sync request does not set the session owner in Request.
> As a result, the leader keeps printing:
> 2010-07-01 10:55:36,733 - INFO  [ProcessThread:-1:preprequestproces...@405] - 
> Got user-level KeeperException when processing sessionid:0x298d3b1fa9 
> type:sync: cxid:0x6 zxid:0xfffe txntype:unknown reqpath:/ Error 
> Path:null Error:KeeperErrorCode = Session moved

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

[jira] Updated: (ZOOKEEPER-884) Remove LedgerSequence references from BookKeeper documentation and comments in tests

[Mahadev konar (JIRA)]

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

Mahadev konar updated ZOOKEEPER-884:


Fix Version/s: 3.4.0

> Remove LedgerSequence references from BookKeeper documentation and comments 
> in tests 
> -
>
> Key: ZOOKEEPER-884
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-884
> Project: Zookeeper
>  Issue Type: Bug
>  Components: contrib-bookkeeper
>Affects Versions: 3.3.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-884.patch
>
>
> We no longer use LedgerSequence, so we need to remove references in 
> documentation and comments sprinkled throughout the code.

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

[jira] Updated: (ZOOKEEPER-913) Version parser fails to parse "3.3.2-dev" from build.xml.

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-913:
---

Fix Version/s: 3.4.0
 Assignee: Anthony Urso

I like the "version" patch better. However it should be made more general.

We've had problems with this before. We should parse X.Y.Zblah where anything 
after Z (Z expected to be a number) gets put into some additional field 
("extension"?). 

> Version parser fails to parse "3.3.2-dev" from build.xml.
> -
>
> Key: ZOOKEEPER-913
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
> Project: Zookeeper
>  Issue Type: Bug
>  Components: build
>Affects Versions: 3.3.1
>Reporter: Anthony Urso
>Assignee: Anthony Urso
>Priority: Critical
> Fix For: 3.4.0
>
> Attachments: zk-build.patch, zk-version.patch
>
>
> Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
> parse "3.3.2-dev".
> version-info:
>  [java] All version-related parameters must be valid integers!
>  [java] Exception in thread "main" java.lang.NumberFormatException: For 
> input string: "2-dev"
>  [java]   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>  [java]   at java.lang.Integer.parseInt(Integer.java:481)
>  [java]   at java.lang.Integer.parseInt(Integer.java:514)
>  [java]   at 
> org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
>  [java] Java Result: 1

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

[jira] Updated: (ZOOKEEPER-912) ZooKeeper client logs trace and debug messages at level INFO

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-912:
---

Fix Version/s: 3.4.0
 Assignee: Anthony Urso
   Issue Type: Improvement  (was: Bug)

IMO more of an improvement than a bug. 

See this section on logging for our general guidelines (granted it's a very 
gray area)
http://hadoop.apache.org/zookeeper/docs/current/zookeeperInternals.html#sc_logging

I see some issues with this patch, while the original logging does make it a 
bit more "fuzzy" some of this is pretty critical information. I'd like to give 
detailed feedback/discussion though. Apache just opened a reviewboard instance, 
could you post the patch there for review?

https://reviews.apache.org/dashboard/

Also please post patches in ZOOKEEPER-###.patch form (also has detail on how to 
create the patch file itself):
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute

Thanks!

> ZooKeeper client logs trace and debug messages at level INFO
> 
>
> Key: ZOOKEEPER-912
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-912
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: java client
>Affects Versions: 3.3.1
>Reporter: Anthony Urso
>Assignee: Anthony Urso
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: zk-loglevel.patch
>
>
> ZK logs a lot of uninformative trace and debug messages to level INFO.  This 
> fuzzes up everything and makes it easy to miss useful log info. 

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

Re: Allowing a ZooKeeper server to be part of multiple clusters

[Flavio Junqueira]

That proposal came in the context of federated zookeeper, and the motivation at the time was to use multiple overlapping clusters to enable increasing write throughput as we increase the number of servers. To my knowledge, we haven't made any progress on the implementation of such a feature.I'd be curious to understand what scenario Vishal envision for such a 2-node cluster feature. If it is not federated, then we would have trouble with ZooKeeper because we rely upon one single leader to generate state updates. In the federated case, there is one leader (perhaps multiple during non-overlapping periods of time) for each     partition.There is this wiki page I have written a while back:	http://wiki.apache.org/hadoop/ZooKeeper/PartitionedZookeeperHope it helps.-FlavioOn Oct 25, 2010, at 11:24 PM, Vishal K wrote:Hi Mahadev,It lets one run multiple 2-node clusters. Suppose I have an application thatdoes a simple 2-way mirroring of my data and uses ZK for clustering. If Ineed to support many 2-node clusters, where will I find the spare machinesto run the third instance for each cluster?-VishalOn Mon, Oct 25, 2010 at 5:14 PM, Mahadev Konar wrote:Hi Vishal, This idea  (2.) had been kicked around intially by Flavio. I think he¹llprobably chip in on the discussion. I am just curious on the whats the ideabehind your proposal? Is this to provide some kind of failure gauranteesbetween a 2 node and 3 node cluster?ThanksmahadevOn 10/25/10 1:05 PM, "Vishal K"  wrote:Hi All,I am thinking about the choices one would have to support multiple 2-nodeclusters. Assume that for some reason one needs to support multiple2-nodeclusters.This would mean they will have to figure out a way to run a thirdinstanceof ZK server for each cluster somewhere to ensure that a ZK cluster isavailable after a failure.This works well if we have to run one or two 2-node clusters. However,whatif we have to run many 2-node clusters?I have following options:1. Find m machines to run the third instance of each cluster. Run n/minstances of ZK on each machine.2. Modify ZooKeeper server to participate in multiple clusters. This willallow us to run y instances of third node where each instance will bepartof n/y clusters.3. Run the third instance of ZK server required for the ith cluster ononeof the server on (i+1)%n cluster. Essentially, distribute the thirdinstanceacross the other clusters.The pros and cons of each approach are fairly obvious. While I prefer thethird approach, I would like to check what everyone thinks about thesecondapproach.Thanks.-Vishal flaviojunqueira research scientist f...@yahoo-inc.comdirect +34 93-183-8828 avinguda diagonal 177, 8th floor, barcelona, 08018, esphone (408) 349 3300fax (408) 349 3301