Re: [VOTE] Release ZooKeeper 3.3.2 (candidate 0)

2010-11-10 Thread Stack
+1

I put it up on a cluster under hbase and ran loads against it over
last few hours.  Nothing untoward in logs.  Played around w/ zkcli.
It seems to behaving same as 3.3.1.

St.Ack


On Wed, Nov 10, 2010 at 3:24 PM, Henry Robinson he...@cloudera.com wrote:
 +1

 Python looks good.

 On 10 November 2010 14:51, Michi Mutsuzaki mic...@yahoo-inc.com wrote:

 +1.

 I ran my benchmark test on the release candidate for one hour, and got
 similar numbers as 3.3.0.

 --Michi

 On 11/10/10 11:09 AM, Mahadev Konar maha...@yahoo-inc.com wrote:

  +1 for the release.
 
  Ran ant test and a couple of smoke tests. Create znodes and shutdown
  zookeeper servers to test durability. Deleted znodes to make sure they
 are
  deleted. Shot down servers one at a time to confirm correct behavior.
 
  Thanks
  mahadev
 
 
  On 11/4/10 11:17 PM, Patrick Hunt ph...@apache.org wrote:
 
  I've created a candidate build for ZooKeeper 3.3.2. This is a bug fix
  release addressing twenty-six issues (eight critical) -- see the
  release notes for details.
 
  *** Please download, test and VOTE before the
  *** vote closes 11pm pacific time, Tuesday, November 9.***
 
  http://people.apache.org/~phunt/zookeeper-3.3.2-candidate-0/
 
  Should we release this?
 
  Patrick
 
 
 




 --
 Henry Robinson
 Software Engineer
 Cloudera
 415-994-6679



Re: [VOTE] Release ZooKeeper 3.3.1 (candidate 0)

2010-05-13 Thread Stack
+1

I installed it under hbase cluster as a 5-node ensemble.  Looks like
it works like 3.3.0.  Did some messing sending nc commands.  No prob.

St.Ack

On Thu, May 13, 2010 at 4:52 PM, Mahadev Konar maha...@yahoo-inc.com wrote:
 +1.

 Ran ant tests and some manual testing to bring up a cluster and run manual
 commands on the zookeeper cluster of 1,3, 5 nodes.

 Thanks
 Mahadev

 On 5/11/10 10:32 PM, Patrick Hunt ph...@apache.org wrote:

 +1, tests pass for me, also verified that nc/zktop worked properly on a
 real cluster (4letter word fix).

 Patrick

 On 05/07/2010 11:25 AM, Patrick Hunt wrote:
 I've created a candidate build for ZooKeeper 3.3.1. This is a bug fix
 release addressing seventeen issues (one critical) -- see the release
 notes for details.

 *** Please download, test and VOTE before the
 *** vote closes 11am pacific time, Wednesday, May 12.***

 http://people.apache.org/~phunt/zookeeper-3.3.1-candidate-0/

 Should we release this?

 Patrick









Re: [VOTE] Release ZooKeeper 3.3.0 (candidate 0)

2010-03-27 Thread Stack
Thanks Patrick for the detail (Support of the quality below puts us
hbasistas at ease about our deciscion to bet the farm on zk making our
next major release).
St.Ack

On Thu, Mar 25, 2010 at 3:57 PM, Patrick Hunt ph...@apache.org wrote:
 Some background on this: In order to add new features (sometimes to fix
 bugs) we need to change the client lib in a non-b/w compatible way, this is
 infrequent, but there's just no way around this in some cases. At the server
 level we always ensure (and even in extreme cases this might not be
 possible, but so far it has) that a new server can talk to an old (at least
 1 version back) client. Additionally we also ensure that a new server can
 talk to an old server, this allows rolling upgrade of the ensemble. WRT
 this approach I'm probably not telling you anything you don't already know
 from your own/prior projects.

 In zk THIS IS CRITICAL to our primary project level goals of high
 availability. It would be laughable if we bill ourselves as highly
 available but sorry, you need to shut everything down then upgrade
 everything to a new version. That's just not acceptable.

 The roadmap has some detail on this, but it's out of date from our current
 practices. We also need to include this information in our release notes.
 http://wiki.apache.org/hadoop/ZooKeeper/Roadmap
 https://issues.apache.org/jira/browse/ZOOKEEPER-727

 Stack, in your specific case you are seeing that 3.3 client works fine with
 3.2 server. In 3.3 we added a new API method to the client, which sends a
 new message type to the server. As long as you don't use this method
 (getchildren2) it will probably work fine. However, we don't officially
 support this configuration as we don't design for this case (the changes)
 and we don't test for this. It may be that there was some semantic change at
 the protocol (client-server protocol) level, that may not be exposed except
 in unusual cases. Perhaps if we had more resources we could verify this case
 (3.3C with 3.2S) but today we do not, so essentially it would be use at
 your own risk.

 Hope this helps. If you have further insights, esp wrt HBase using ZK please
 feel free to comment.

 Regards,

 Patrick

 Stack wrote:

 Patrick just let me know that newer client talking to older server is
 not supported.  I didn't know that.  Thanks for pointing it out.  Was
 sort of surprised it worked at all so just noted this aspect of my zk
 3.3.0 RC0 eval.

 Congrats on new release lads,
 St.Ack

 P.S. Below is backup of my assertion 3.3.0 client basically works
 against 3.2.2 ensemble:


 In client log I see this:

 2010-03-25 12:23:57,670 INFO org.apache.zookeeper.ZooKeeper: Client
 environment:zookeeper.version=3.3.0-925362, built on 03/19/2010 18:38
 GMT

 ...

 Then this:

 2010-03-25 12:23:57,672 INFO org.apache.zookeeper.ZooKeeper:
 Initiating client connection,

 connectString=sv2borg165:2181,sv2borg166:2181,sv2borg167:2181,sv2borg169:2181,sv2borg164:2181
 sessionTimeout=6 watcher=Thread[Thread-0,5,main]
 2010-03-25 12:23:57,683 INFO org.apache.zookeeper.ClientCnxn: Opening
 socket connection to server sv2borg166/10.20.20.166:2181
 2010-03-25 12:23:57,686 INFO org.apache.zookeeper.ClientCnxn: Socket
 connection established to sv2borg166/10.20.20.166:2181, initiating
 session

 ..

 Over on 166 I see...

 2010-03-25 12:23:57,697 INFO
 org.apache.zookeeper.server.NIOServerCnxn: Connected to
 /10.20.20.185:46331 lastZxid 0
 2010-03-25 12:23:57,725 INFO
 org.apache.zookeeper.server.NIOServerCnxn: Creating new session
 0x3266d5140d70759
 2010-03-25 12:23:57,726 INFO
 org.apache.zookeeper.server.NIOServerCnxn: Finished init of
 0x3266d5140d70759 valid:true
 2010-03-25 12:25:07,305 INFO
 org.apache.zookeeper.server.NIOServerCnxn: Processing stat command
 from /10.20.20.185:60661
 2010-03-25 12:25:07,306 WARN
 org.apache.zookeeper.server.NIOServerCnxn: Exception causing close of
 session 0x0 due to java.io.IOException: Responded to info probe
 2010-03-25 12:25:07,306 INFO
 org.apache.zookeeper.server.NIOServerCnxn: closing session:0x0
 NIOServerCnxn: java.nio.channels.SocketChannel[connected
 local=/10.20.20.166:2181 remote=/10.20.20.185:60661]

 ...

 If I do stat over there I see Zookeeper version: 3.2.2-888565, built
 on 12/08/2009 21:51 GMT...


 On Thu, Mar 25, 2010 at 2:00 PM, Patrick Hunt ph...@apache.org wrote:

 Stack, you can't use a new client with an old server. We support b/w
 compatibility at the server level (new server works with old client) but
 not
 the other way around. You would have to upgrade the server and client at
 the
 same time, or upgrade the servers (rolling upgrade) then upgrade the
 clients.

 Patrick

 Stack wrote:

 +1

 All hbase tests pass with 3.3.0 in place.  I ran small loading and
 nothing odd looking.  Looks like no issue having a zk 3.3.0 client
 talk to a 3.2.2 ensemble.

 Requires small mods to hbase other than dropping new zk jar into
 hbase/lib in place of zk 3.2.2: HBASE-2380.

 St.Ack

 On Fri, Mar 19, 2010

Re: [VOTE] Release ZooKeeper 3.2.2 (candidate 1)

2009-12-09 Thread stack
+1

Put it under hbase and ran a loading on a small cluster.  Completed.

Checked out doc.  Looks right on cursory glance.

St.Ack


On Tue, Dec 8, 2009 at 2:32 PM, Patrick Hunt ph...@apache.org wrote:

 I've created a second candidate build for ZooKeeper 3.2.2. This is a bug
 fix release addressing 13 issues (three critical) -- see the release notes
 for details.

 *** Please download, test and VOTE before the
 *** vote closes 3pm pacific time, Friday, December 11.***

 http://people.apache.org/~phunt/zookeeper-3.2.2-candidate-1/http://people.apache.org/%7Ephunt/zookeeper-3.2.2-candidate-1/

 Should we release this?

 Patrick








Re: [Fwd: [VOTE] Release ZooKeeper 3.2.2 (candidate 0)]

2009-11-24 Thread stack
+1 Ran it in place of zk-3.2.1 in hbase context for an upload and nothing
untoward examining logs.  Took a quick gander at the doc. and nothing
obviously amiss.

St.Ack



On Mon, Nov 23, 2009 at 4:53 PM, Patrick Hunt ph...@apache.org wrote:

 Hadoop PMC,

 Please test and vote on this release in zookeeper-dev list.

 Thanks,

 Patrick

 I've created a candidate build for ZooKeeper 3.2.2. This is a bug fix
 release addressing eleven issues (two critical) -- see the release notes for
 details.

 *** Please download, test and VOTE before the
 *** vote closes 5pm pacific time, Friday, November 27.***

 http://people.apache.org/~phunt/zookeeper-3.2.2-candidate-0/http://people.apache.org/%7Ephunt/zookeeper-3.2.2-candidate-0/

 Should we release this?

 Patrick









[jira] Created: (ZOOKEEPER-595) A means of asking quorum what conifguration it is running with

2009-11-24 Thread stack (JIRA)
A means of asking quorum what conifguration it is running with
--

 Key: ZOOKEEPER-595
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-595
 Project: Zookeeper
  Issue Type: Improvement
Reporter: stack


I'd like to ask a running quorum what its configuration is.  I'd want to know 
stuff like session timeout and tick times.

Use case is that in hbase there is no zoo.cfg usually; the configuration is 
manufactured and piped to the starting zk server.  I want to know if all of the 
manufactured config. 'took' or how zk interpreted it.

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



[jira] Commented: (ZOOKEEPER-587) client should log timeout negotiated with server

2009-11-21 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12781074#action_12781074
 ] 

stack commented on ZOOKEEPER-587:
-

If server changes the timeout on the client, yeah, for sure at least log it.  
Good stuff.

 client should log timeout negotiated with server
 

 Key: ZOOKEEPER-587
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-587
 Project: Zookeeper
  Issue Type: Bug
  Components: c client, java client
Affects Versions: 3.2.1
Reporter: Patrick Hunt
 Fix For: 3.3.0


 The ZK client should log the timeout negotiated with the server if the time 
 is different than the timeout parameter specified by the client.

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