[jira] Updated: (ZOOKEEPER-374) Uninitialized struct variable in C causes warning which is treated as an error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-374: --- Attachment: ZOOKEEPER-374.patch fixed warning and added tests to verify > Uninitialized struct variable in C causes warning which is treated as an error > -- > > Key: ZOOKEEPER-374 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-374 > Project: Zookeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.1.1 > Environment: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. > build 5490) >Reporter: Nitay Joffe >Priority: Trivial > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-374.patch > > > nitay-joffes-macbook-pro:c nitay$ pwd > /Users/nitay/code/zookeeper/src/c > nitay-joffes-macbook-pro:c nitay$ make > make all-am > /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo > -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f 'src/zookeeper.c' > || echo './'`src/zookeeper.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests > -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF > .deps/zookeeper.Tpo -c src/zookeeper.c -fno-common -DPIC -o .libs/zookeeper.o > cc1: warnings being treated as errors > src/zookeeper.c: In function 'zoo_add_auth': > src/zookeeper.c:2378: warning: 'auth.buff' may be used uninitialized in this > function > src/zookeeper.c:2378: warning: 'auth.len' may be used uninitialized in this > function > make[1]: *** [zookeeper.lo] Error 1 > make: *** [all] Error 2 > Need to set auth.buff and auth.len to zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-374) Uninitialized struct variable in C causes warning which is treated as an error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-374: -- Assignee: Patrick Hunt > Uninitialized struct variable in C causes warning which is treated as an error > -- > > Key: ZOOKEEPER-374 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-374 > Project: Zookeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.1.1 > Environment: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. > build 5490) >Reporter: Nitay Joffe >Assignee: Patrick Hunt >Priority: Trivial > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-374.patch > > > nitay-joffes-macbook-pro:c nitay$ pwd > /Users/nitay/code/zookeeper/src/c > nitay-joffes-macbook-pro:c nitay$ make > make all-am > /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo > -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f 'src/zookeeper.c' > || echo './'`src/zookeeper.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests > -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF > .deps/zookeeper.Tpo -c src/zookeeper.c -fno-common -DPIC -o .libs/zookeeper.o > cc1: warnings being treated as errors > src/zookeeper.c: In function 'zoo_add_auth': > src/zookeeper.c:2378: warning: 'auth.buff' may be used uninitialized in this > function > src/zookeeper.c:2378: warning: 'auth.len' may be used uninitialized in this > function > make[1]: *** [zookeeper.lo] Error 1 > make: *** [all] Error 2 > Need to set auth.buff and auth.len to zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-374) Uninitialized struct variable in C causes warning which is treated as an error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-374: --- Status: Patch Available (was: Open) > Uninitialized struct variable in C causes warning which is treated as an error > -- > > Key: ZOOKEEPER-374 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-374 > Project: Zookeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.1.1 > Environment: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. > build 5490) >Reporter: Nitay Joffe >Assignee: Patrick Hunt >Priority: Trivial > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-374.patch > > > nitay-joffes-macbook-pro:c nitay$ pwd > /Users/nitay/code/zookeeper/src/c > nitay-joffes-macbook-pro:c nitay$ make > make all-am > /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo > -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f 'src/zookeeper.c' > || echo './'`src/zookeeper.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests > -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF > .deps/zookeeper.Tpo -c src/zookeeper.c -fno-common -DPIC -o .libs/zookeeper.o > cc1: warnings being treated as errors > src/zookeeper.c: In function 'zoo_add_auth': > src/zookeeper.c:2378: warning: 'auth.buff' may be used uninitialized in this > function > src/zookeeper.c:2378: warning: 'auth.len' may be used uninitialized in this > function > make[1]: *** [zookeeper.lo] Error 1 > make: *** [all] Error 2 > Need to set auth.buff and auth.len to zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: ZooKeeper-trunk #280
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/280/changes Changes: [mahadev] ZOOKEEPER-361. integrate cppunit testing as part of hudson patch process. (giri via mahadev) -- [...truncated 54082 lines...] [junit] 2009-04-15 05:32:39,078 - INFO [main:finalrequestproces...@268] - shutdown of request processor complete [junit] 2009-04-15 05:32:39,078 - INFO [SyncThread:0:syncrequestproces...@119] - SyncRequestProcessor exited! [junit] 2009-04-15 05:32:39,080 - INFO [ProcessThread:-1:preprequestproces...@111] - PrepRequestProcessor exited loop! [junit] 2009-04-15 05:32:39,180 - INFO [main:clientb...@306] - STARTING server [junit] 2009-04-15 05:32:39,181 - INFO [main:zookeeperser...@160] - Created server [junit] 2009-04-15 05:32:39,182 - INFO [main:files...@71] - Reading snapshot http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/ws/trunk/build/test/tmp/test8340474231230349885.junit.dir/version-2/snapshot.0 [junit] 2009-04-15 05:32:39,183 - INFO [main:filetxnsnap...@198] - Snapshotting: 3 [junit] 2009-04-15 05:32:39,185 - INFO [NIOServerCxn.Factory:33221:nioserverc...@635] - Processing stat command from /127.0.0.1:51772 [junit] 2009-04-15 05:32:39,185 - WARN [NIOServerCxn.Factory:33221:nioserverc...@431] - Exception causing close of session 0x0 due to java.io.IOException: Responded to info probe [junit] 2009-04-15 05:32:39,185 - INFO [NIOServerCxn.Factory:33221:nioserverc...@766] - closing session:0x0 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:51772] [junit] 2009-04-15 05:32:40,889 - INFO [main-SendThread:clientcnxn$sendthr...@800] - Attempting connection to server /127.0.0.1:33221 [junit] 2009-04-15 05:32:40,889 - INFO [main-SendThread:clientcnxn$sendthr...@716] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:51773 remote=/127.0.0.1:33221] [junit] 2009-04-15 05:32:40,890 - INFO [main-SendThread:clientcnxn$sendthr...@868] - Server connection successful [junit] 2009-04-15 05:32:40,890 - INFO [NIOServerCxn.Factory:33221:nioserverc...@517] - Connected to /127.0.0.1:51773 lastZxid 3 [junit] 2009-04-15 05:32:40,890 - INFO [NIOServerCxn.Factory:33221:nioserverc...@895] - Finished init of 0x120a8433914 valid:true [junit] 2009-04-15 05:32:40,891 - INFO [NIOServerCxn.Factory:33221:nioserverc...@545] - Renewing session 0x120a8433914 [junit] 2009-04-15 05:32:42,000 - INFO [SessionTracker:sessiontrackeri...@142] - SessionTrackerImpl exited loop! [junit] 2009-04-15 05:32:42,001 - INFO [SessionTracker:sessiontrackeri...@142] - SessionTrackerImpl exited loop! [junit] 2009-04-15 05:33:14,902 - INFO [main:clientb...@300] - STOPPING server [junit] 2009-04-15 05:33:14,903 - INFO [main:nioserverc...@766] - closing session:0x120a8433914 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:51773] [junit] 2009-04-15 05:33:14,904 - WARN [main-SendThread:clientcnxn$sendthr...@898] - Exception closing session 0x120a8433914 to sun.nio.ch.selectionkeyi...@147358f [junit] java.io.IOException: Read error rc = -1 java.nio.DirectByteBuffer[pos=0 lim=4 cap=4] [junit] at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:632) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:876) [junit] 2009-04-15 05:33:14,904 - INFO [NIOServerCxn.Factory:33221:nioservercnxn$fact...@177] - NIOServerCnxn factory exited run method [junit] 2009-04-15 05:33:14,905 - INFO [main:finalrequestproces...@268] - shutdown of request processor complete [junit] 2009-04-15 05:33:14,905 - INFO [ProcessThread:-1:preprequestproces...@111] - PrepRequestProcessor exited loop! [junit] 2009-04-15 05:33:14,905 - INFO [SyncThread:0:syncrequestproces...@119] - SyncRequestProcessor exited! [junit] 2009-04-15 05:33:15,000 - INFO [SessionTracker:sessiontrackeri...@142] - SessionTrackerImpl exited loop! [junit] 2009-04-15 05:33:15,004 - INFO [main:clientb...@306] - STARTING server [junit] 2009-04-15 05:33:15,005 - INFO [main:zookeeperser...@160] - Created server [junit] 2009-04-15 05:33:15,006 - INFO [main:files...@71] - Reading snapshot http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/ws/trunk/build/test/tmp/test8340474231230349885.junit.dir/version-2/snapshot.3 [junit] 2009-04-15 05:33:15,008 - INFO [main:filetxnsnap...@198] - Snapshotting: 5 [junit] 2009-04-15 05:33:15,010 - INFO [NIOServerCxn.Factory:33221:nioserverc...@635] - Processing stat command from /127.0.0.1:51775 [junit] 2009-04-15 05:33:15,010 - WARN [NIOServerCxn.Factory:33221:nioserverc...@431] - Exception causing close of session 0x0 due to java.io.IOException: Responded to info probe [junit] 2009-04-15 05:33:15,011 - INFO [NI
[jira] Commented: (ZOOKEEPER-224) Deploy ZooKeeper 3.0.0 to a Maven Repository
[ https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699044#action_12699044 ] Giridharan Kesavan commented on ZOOKEEPER-224: -- Hadoop-core is yet to be published to the maven repo. With HADOOP-3305 we have dependencies managed by ivy. Publishing hadoop-core to the mvn repo requires some more work :) I will be workin on this soon. > Deploy ZooKeeper 3.0.0 to a Maven Repository > > > Key: ZOOKEEPER-224 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-224 > Project: Zookeeper > Issue Type: Task > Components: build >Affects Versions: 3.0.0 >Reporter: Hiram Chirino >Assignee: Patrick Hunt >Priority: Critical > > I've created the maven poms needed for the 3.0.0 release. > The directory structure and artifacts located at: > http://people.apache.org/~chirino/zk-repo/ > aka > people.apache.org:/x1/users/chirino/public_html/zk-repo > Just need sto get GPG signed by the project KEY and deployed to: > people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository > Who's the current ZooKeeper release manager? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Status: Patch Available (was: Open) patch build stuck on hudson for more that 10Hrs. I killed the patch build. Resubmitting the patch to hudson. tnx > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.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-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Status: Open (was: Patch Available) > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-371) to implement jdiff
[
https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699040#action_12699040
]
Giridharan Kesavan commented on ZOOKEEPER-371:
--
{quote}
run jdiff on svn trunk and then run jdiff on svn trunk+patch. If their is a
change then we -1 the patch. That way we do not need to check in the 3.1.1 api
docs. can we do that or doing what you suggest is the right way to go?
{quote}
This patch that I submitted is to run during the nightly to show up any any
changes b/w 3.1.1 and 3.2.0.
But I understand the requirement that we want this jdiff as part of the path
test process, that way we can say whether a path has introduced any api changes
and do a +1/-1 based on that. I already have this in my task list and I would
be working on this enhancement soon.
tnx
> to implement jdiff
> ---
>
> Key: ZOOKEEPER-371
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371
> Project: Zookeeper
> Issue Type: Improvement
> Components: build
>Affects Versions: 3.2.0
> Environment: to implement jdiff
>Reporter: Giridharan Kesavan
>Assignee: Giridharan Kesavan
> Fix For: 3.2.0
>
> Attachments: zookeeper-371.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ZOOKEEPER-371) to implement jdiff
[
https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699040#action_12699040
]
Giridharan Kesavan edited comment on ZOOKEEPER-371 at 4/14/09 8:44 PM:
---
{quote}
run jdiff on svn trunk and then run jdiff on svn trunk+patch. If their is a
change then we -1 the patch. That way we do not need to check in the 3.1.1 api
docs. can we do that or doing what you suggest is the right way to go?
{quote}
This patch that I submitted is to run during the nightly to show up any changes
b/w 3.1.1 and 3.2.0.
But I understand the requirement that we want this jdiff as part of the patch
test process, that way we can say whether a patch has introduced any api
changes and do a +1/-1 based on that. I already have this in my task list and
I would be working on this enhancement soon.
tnx
was (Author: gkesavan):
{quote}
run jdiff on svn trunk and then run jdiff on svn trunk+patch. If their is a
change then we -1 the patch. That way we do not need to check in the 3.1.1 api
docs. can we do that or doing what you suggest is the right way to go?
{quote}
This patch that I submitted is to run during the nightly to show up any any
changes b/w 3.1.1 and 3.2.0.
But I understand the requirement that we want this jdiff as part of the path
test process, that way we can say whether a path has introduced any api changes
and do a +1/-1 based on that. I already have this in my task list and I would
be working on this enhancement soon.
tnx
> to implement jdiff
> ---
>
> Key: ZOOKEEPER-371
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371
> Project: Zookeeper
> Issue Type: Improvement
> Components: build
>Affects Versions: 3.2.0
> Environment: to implement jdiff
>Reporter: Giridharan Kesavan
>Assignee: Giridharan Kesavan
> Fix For: 3.2.0
>
> Attachments: zookeeper-371.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699037#action_12699037 ] Mahadev konar commented on ZOOKEEPER-371: - giri, I think what ben meant was -- run jdiff on svn trunk and then run jdiff on svn trunk+patch. If their is a change then we -1 the patch. That way we do not need to check in the 3.1.1 api docs. can we do that or doing what you suggest is the right way to go? > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699034#action_12699034 ] Giridharan Kesavan commented on ZOOKEEPER-371: -- Please correct me if I'm wrong. patch contains api for 3.1.1(zookeeper_3.1.1.xml) and tha api-xml target would generate the api doc for 3.2.0(trunk version) This 3.1.1 api doc is required to compare the api changes b/w 3.1.1 and 3.2.0. Thanks, > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FastLeaderElection
Flavio, Thanks for the detailed answer. Makes sense. -Raghu - Original Message From: Flavio Junqueira To: "rag...@yahoo.com" Cc: zookeeper-dev@hadoop.apache.org Sent: Tuesday, 14 April, 2009 9:21:35 Subject: Re: FastLeaderElection Hi Raghu, I'm glad that you going deep into the code, so thanks for all your questions. In your description below, you say that a faulty peer gets back. If it gets back, then it is not faulty, right? To be more concrete, suppose that this peer was partitioned away, and it now ends up being elected because it has a zxid higher than everyone else. I would say that this behavior is correct. The behavior we are trying to avoid is different. Suppose that the current leader CL crashes and a new leader NL arises. Suppose also that NL crashes before followers are able to connect to NL. In this case, followers will move on to another round of leader election. If there is a slow process that didn't finish the election of NL, but has NL as its current candidate, then it will propose it again and without the notion of rounds, server will accept the notification from the slow process. Thanks, -Flavio On Apr 14, 2009, at 5:10 PM, rag...@yahoo.com wrote: > > Falvio, > > Thanks for explaining this. > > When the faulty peer gets back and attempts to propose itself as the leader, > it's clear that all the other peers don't consider its proposal and notify > the faulty peer that they are in a higher epoch. However, the faulty peer > will sync up its logical clock upon receiving the first notification from a > higher epoch and resend a proposal notification to all with itself as the > proposed leader (because it's zxid is higher). If the other peers haven't > completed the election loop by the time the updated notificaiton is received > from the faulty peer, they will succumb again, update their proposal record > and send notifications to all others with faulty peer as the proposed leader. > > So the logical clock only seems to be buying some time here, rather than > completely eliminating the faulty peer. The code seems to be hoping that the > rest of the peers will complete their election loop and start following a new > leader by the time the faulty peer syncs up its logical clock and notifies > other peers. Is my understanding correct? > > -Raghu > > > > - Original Message > From: Flavio Junqueira > To: zookeeper-dev@hadoop.apache.org > Cc: rag...@yahoo.com > Sent: Monday, 13 April, 2009 15:08:10 > Subject: Re: FastLeaderElection > > Hi Raghu, Upon multiple consecutive crashes (or perhaps a network partition), > it is possible that we keep electing a faulty server if we only use zxid. We > avoid such a problem using a logical clock as servers only consider changing > their proposals if they received a notification from the same or a later > epoch. With this mechanism, if an elected server crashes before exercising > its role as a leader, it won't be considered in later epochs. Without a > logical clock, a server lagging behind in the election could re-introduce the > faulty server into the election, and it would be elected again if the faulty > server is the one with highest zxid. > > Note that we are not using "logical clocks" in the sense of Lamport clocks. > We are not incrementing upon every event, but instead only counting rounds of > leader election. > > -Flavio > > On Apr 13, 2009, at 8:55 PM, rag...@yahoo.com wrote: > >> >> Could someone please throw some light on this? Thanks. >> >> -Raghu >> >> >> >> - Original Message >> From: "rag...@yahoo.com" >> To: zookeeper-u...@hadoop.apache.org >> Sent: Friday, 10 April, 2009 8:11:34 >> Subject: FastLeaderElection >> >> >> Hi, >> >> Could someone please explain quickly why logical clock is used in >> FastLeaderElection? It looks to me like the peers can converge on a leader >> (with highest zxid or server id if zxids are the same) even without the >> logical clock. May be I am missing something here, I could not figure out >> why logical clock is needed. >> >> Thanks >> Raghu >> >> >> > > >
[jira] Updated: (ZOOKEEPER-367) RecoveryTest failure - "unreasonable length" IOException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-367: Status: Patch Available (was: Open) > RecoveryTest failure - "unreasonable length" IOException > > > Key: ZOOKEEPER-367 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-367 > Project: Zookeeper > Issue Type: Bug > Components: server >Affects Versions: 3.2.0 > Environment: ubuntu 8.10 intrpid ibex, jvm 1.6.0_10 >Reporter: Patrick Hunt >Assignee: Mahadev konar >Priority: Critical > Fix For: 3.2.0 > > Attachments: invalid1.tar.gz, invalidsnap.tar.gz, rec.tar.gz, > rep2.tar.gz, TEST-org.apache.zookeeper.test.RecoveryTest.txt, > ZOOKEEPER-367.patch, ZOOKEEPER-367.patch > > > during local testing I received the attached recoverytest failure -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-367) RecoveryTest failure - "unreasonable length" IOException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-367: Attachment: invalidsnap.tar.gz ZOOKEEPER-367.patch this patch adds a test. also for the test we have to check in the data files that pat posted so that we can run the test with the data file. I am uploading the datafiles as tar.gz. You will need to untar the tar.gz in src/java/test/data and then svn add src/java/test/data/invalidsnap. the patch will fail the automated testing just becasue the patch cannot have the binary files. > RecoveryTest failure - "unreasonable length" IOException > > > Key: ZOOKEEPER-367 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-367 > Project: Zookeeper > Issue Type: Bug > Components: server >Affects Versions: 3.2.0 > Environment: ubuntu 8.10 intrpid ibex, jvm 1.6.0_10 >Reporter: Patrick Hunt >Assignee: Mahadev konar >Priority: Critical > Fix For: 3.2.0 > > Attachments: invalid1.tar.gz, invalidsnap.tar.gz, rec.tar.gz, > rep2.tar.gz, TEST-org.apache.zookeeper.test.RecoveryTest.txt, > ZOOKEEPER-367.patch, ZOOKEEPER-367.patch > > > during local testing I received the attached recoverytest failure -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-374) Uninitialized struct variable in C causes warning which is treated as an error
[
https://issues.apache.org/jira/browse/ZOOKEEPER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698968#action_12698968
]
Patrick Hunt commented on ZOOKEEPER-374:
Interesting, with gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2
this warning is not output by the compiler. Seems that the newer version
of the compiler is able to determine that auth is only accessed (written/read)
when the following
condition is true:
if(cert!=NULL && certLen!=0){
as a result it doesn't complain in this instance on my system.
I'll submit a patch for this to work on older gccs.
> Uninitialized struct variable in C causes warning which is treated as an error
> --
>
> Key: ZOOKEEPER-374
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-374
> Project: Zookeeper
> Issue Type: Bug
> Components: c client
>Affects Versions: 3.1.1
> Environment: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc.
> build 5490)
>Reporter: Nitay Joffe
>Priority: Trivial
> Fix For: 3.2.0
>
>
> nitay-joffes-macbook-pro:c nitay$ pwd
> /Users/nitay/code/zookeeper/src/c
> nitay-joffes-macbook-pro:c nitay$ make
> make all-am
> /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo
> -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f 'src/zookeeper.c'
> || echo './'`src/zookeeper.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests
> -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF
> .deps/zookeeper.Tpo -c src/zookeeper.c -fno-common -DPIC -o .libs/zookeeper.o
> cc1: warnings being treated as errors
> src/zookeeper.c: In function 'zoo_add_auth':
> src/zookeeper.c:2378: warning: 'auth.buff' may be used uninitialized in this
> function
> src/zookeeper.c:2378: warning: 'auth.len' may be used uninitialized in this
> function
> make[1]: *** [zookeeper.lo] Error 1
> make: *** [all] Error 2
> Need to set auth.buff and auth.len to zero.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-337) improve logging in leader election lookForLeader method when address resolution fails
[
https://issues.apache.org/jira/browse/ZOOKEEPER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-337:
---
Status: Patch Available (was: Open)
resubmitting - "already bound address" issue in one of the tests (false
positive) that I hadn't touched.
> improve logging in leader election lookForLeader method when address
> resolution fails
> -
>
> Key: ZOOKEEPER-337
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-337
> Project: Zookeeper
> Issue Type: Improvement
> Components: quorum
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-337.patch, ZOOKEEPER-337.patch,
> ZOOKEEPER-337.patch
>
>
> leader election has the following code:
> requestPacket.setSocketAddress(server.addr);
> LOG.info("Server address: " + server.addr);
> this should be switched to have the info log first, set sock addr second.
> The reason for this is that if the setSocketAddress fails sun is not printing
> the address used. As a result it's verfy difficult to debug this issue.
> If we log the server address first, then if the setsockaddr fails we'll see
> both the address of the server and the exception detail (right now we just
> see the exception detail which does not include the invlaid address in
> invalidaddressexception).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-337) improve logging in leader election lookForLeader method when address resolution fails
[
https://issues.apache.org/jira/browse/ZOOKEEPER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-337:
---
Status: Open (was: Patch Available)
> improve logging in leader election lookForLeader method when address
> resolution fails
> -
>
> Key: ZOOKEEPER-337
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-337
> Project: Zookeeper
> Issue Type: Improvement
> Components: quorum
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-337.patch, ZOOKEEPER-337.patch,
> ZOOKEEPER-337.patch
>
>
> leader election has the following code:
> requestPacket.setSocketAddress(server.addr);
> LOG.info("Server address: " + server.addr);
> this should be switched to have the info log first, set sock addr second.
> The reason for this is that if the setSocketAddress fails sun is not printing
> the address used. As a result it's verfy difficult to debug this issue.
> If we log the server address first, then if the setsockaddr fails we'll see
> both the address of the server and the exception detail (right now we just
> see the exception detail which does not include the invlaid address in
> invalidaddressexception).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-224) Deploy ZooKeeper 3.0.0 to a Maven Repository
[ https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698871#action_12698871 ] Todd Greenwood-Geer commented on ZOOKEEPER-224: --- https://issues.apache.org/jira/browse/HADOOP-3305 The hadoop issue(HADOOP-3305) has been resolved, and it appears that hadoop-core has been deployed to maven. Is there any possibility of deploying zookeeper to maven? > Deploy ZooKeeper 3.0.0 to a Maven Repository > > > Key: ZOOKEEPER-224 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-224 > Project: Zookeeper > Issue Type: Task > Components: build >Affects Versions: 3.0.0 >Reporter: Hiram Chirino >Assignee: Patrick Hunt >Priority: Critical > > I've created the maven poms needed for the 3.0.0 release. > The directory structure and artifacts located at: > http://people.apache.org/~chirino/zk-repo/ > aka > people.apache.org:/x1/users/chirino/public_html/zk-repo > Just need sto get GPG signed by the project KEY and deployed to: > people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository > Who's the current ZooKeeper release manager? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FastLeaderElection
Hi Raghu, I'm glad that you going deep into the code, so thanks for all your questions. In your description below, you say that a faulty peer gets back. If it gets back, then it is not faulty, right? To be more concrete, suppose that this peer was partitioned away, and it now ends up being elected because it has a zxid higher than everyone else. I would say that this behavior is correct. The behavior we are trying to avoid is different. Suppose that the current leader CL crashes and a new leader NL arises. Suppose also that NL crashes before followers are able to connect to NL. In this case, followers will move on to another round of leader election. If there is a slow process that didn't finish the election of NL, but has NL as its current candidate, then it will propose it again and without the notion of rounds, server will accept the notification from the slow process. Thanks, -Flavio On Apr 14, 2009, at 5:10 PM, rag...@yahoo.com wrote: Falvio, Thanks for explaining this. When the faulty peer gets back and attempts to propose itself as the leader, it's clear that all the other peers don't consider its proposal and notify the faulty peer that they are in a higher epoch. However, the faulty peer will sync up its logical clock upon receiving the first notification from a higher epoch and resend a proposal notification to all with itself as the proposed leader (because it's zxid is higher). If the other peers haven't completed the election loop by the time the updated notificaiton is received from the faulty peer, they will succumb again, update their proposal record and send notifications to all others with faulty peer as the proposed leader. So the logical clock only seems to be buying some time here, rather than completely eliminating the faulty peer. The code seems to be hoping that the rest of the peers will complete their election loop and start following a new leader by the time the faulty peer syncs up its logical clock and notifies other peers. Is my understanding correct? -Raghu - Original Message From: Flavio Junqueira To: zookeeper-dev@hadoop.apache.org Cc: rag...@yahoo.com Sent: Monday, 13 April, 2009 15:08:10 Subject: Re: FastLeaderElection Hi Raghu, Upon multiple consecutive crashes (or perhaps a network partition), it is possible that we keep electing a faulty server if we only use zxid. We avoid such a problem using a logical clock as servers only consider changing their proposals if they received a notification from the same or a later epoch. With this mechanism, if an elected server crashes before exercising its role as a leader, it won't be considered in later epochs. Without a logical clock, a server lagging behind in the election could re-introduce the faulty server into the election, and it would be elected again if the faulty server is the one with highest zxid. Note that we are not using "logical clocks" in the sense of Lamport clocks. We are not incrementing upon every event, but instead only counting rounds of leader election. -Flavio On Apr 13, 2009, at 8:55 PM, rag...@yahoo.com wrote: Could someone please throw some light on this? Thanks. -Raghu - Original Message From: "rag...@yahoo.com" To: zookeeper-u...@hadoop.apache.org Sent: Friday, 10 April, 2009 8:11:34 Subject: FastLeaderElection Hi, Could someone please explain quickly why logical clock is used in FastLeaderElection? It looks to me like the peers can converge on a leader (with highest zxid or server id if zxids are the same) even without the logical clock. May be I am missing something here, I could not figure out why logical clock is needed. Thanks Raghu
Re: FastLeaderElection
Falvio, Thanks for explaining this. When the faulty peer gets back and attempts to propose itself as the leader, it's clear that all the other peers don't consider its proposal and notify the faulty peer that they are in a higher epoch. However, the faulty peer will sync up its logical clock upon receiving the first notification from a higher epoch and resend a proposal notification to all with itself as the proposed leader (because it's zxid is higher). If the other peers haven't completed the election loop by the time the updated notificaiton is received from the faulty peer, they will succumb again, update their proposal record and send notifications to all others with faulty peer as the proposed leader. So the logical clock only seems to be buying some time here, rather than completely eliminating the faulty peer. The code seems to be hoping that the rest of the peers will complete their election loop and start following a new leader by the time the faulty peer syncs up its logical clock and notifies other peers. Is my understanding correct? -Raghu - Original Message From: Flavio Junqueira To: zookeeper-dev@hadoop.apache.org Cc: rag...@yahoo.com Sent: Monday, 13 April, 2009 15:08:10 Subject: Re: FastLeaderElection Hi Raghu, Upon multiple consecutive crashes (or perhaps a network partition), it is possible that we keep electing a faulty server if we only use zxid. We avoid such a problem using a logical clock as servers only consider changing their proposals if they received a notification from the same or a later epoch. With this mechanism, if an elected server crashes before exercising its role as a leader, it won't be considered in later epochs. Without a logical clock, a server lagging behind in the election could re-introduce the faulty server into the election, and it would be elected again if the faulty server is the one with highest zxid. Note that we are not using "logical clocks" in the sense of Lamport clocks. We are not incrementing upon every event, but instead only counting rounds of leader election. -Flavio On Apr 13, 2009, at 8:55 PM, rag...@yahoo.com wrote: > > Could someone please throw some light on this? Thanks. > > -Raghu > > > > - Original Message > From: "rag...@yahoo.com" > To: zookeeper-u...@hadoop.apache.org > Sent: Friday, 10 April, 2009 8:11:34 > Subject: FastLeaderElection > > > Hi, > > Could someone please explain quickly why logical clock is used in > FastLeaderElection? It looks to me like the peers can converge on a leader > (with highest zxid or server id if zxids are the same) even without the > logical clock. May be I am missing something here, I could not figure out why > logical clock is needed. > > Thanks > Raghu > > >
[jira] Commented: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698818#action_12698818 ] Benjamin Reed commented on ZOOKEEPER-371: - shouldn't this be generated rather than checked in? > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.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-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Attachment: zookeeper-371.patch > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.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-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Status: Patch Available (was: Open) > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.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-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Status: Open (was: Patch Available) > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Attachment: (was: zookeeper-371.patch) > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Status: Patch Available (was: Open) Mahadev, Could you please review this? tnx! > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.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-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giridharan Kesavan updated ZOOKEEPER-371: - Attachment: zookeeper-371.patch this patch enables jdiff for zookeeper. Tnx! > to implement jdiff > --- > > Key: ZOOKEEPER-371 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.2.0 > Environment: to implement jdiff >Reporter: Giridharan Kesavan >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zookeeper-371.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
