[jira] Issue Comment Edited: (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722245#action_12722245 ] Henry Robinson edited comment on ZOOKEEPER-107 at 6/20/09 12:09 PM: As it turns out, I've pretty much implemented Observers in all but name already - they go through the same connection logic as normal followers, and therefore sync, but are disbarred from sending Leader.REQUEST packets to the leader. Similarly, when a leader is sending a proposal packet it only gets sent to those followers which are in the current view. Since the logic is very similar, and we will be able to distinguish observers from followers by whether they are members of the current view, I haven't duplicated code into Observer* classes. I added this when finding that any new follower can join an existing ensemble and issue proposals to it, even if the static configuration of the ensemble does not contain it. This seemed to deadlock the ensemble pretty quickly :) Edit: of course, this means that Observers can't actually see the payload of a transaction, as per the note on ZK-368. Either the leader sends special packets (INFORM, perhaps) to Observers containing the transaction payload, or the Observers must know not to participate in voting. That said, the Leader will ignore the votes of Observers, but we want to cut down on traffic. was (Author: henryr): As it turns out, I've pretty much implemented Observers in all but name already - they go through the same connection logic as normal followers, and therefore sync, but are disbarred from sending Leader.REQUEST packets to the leader. Similarly, when a leader is sending a proposal packet it only gets sent to those followers which are in the current view. Since the logic is very similar, and we will be able to distinguish observers from followers by whether they are members of the current view, I haven't duplicated code into Observer* classes. I added this when finding that any new follower can join an existing ensemble and issue proposals to it, even if the static configuration of the ensemble does not contain it. This seemed to deadlock the ensemble pretty quickly :) > Allow dynamic changes to server cluster membership > -- > > Key: ZOOKEEPER-107 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Patrick Hunt >Assignee: Henry Robinson > Attachments: SimpleAddition.rtf > > > Currently cluster membership is statically defined, adding/removing hosts > to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722245#action_12722245 ] Henry Robinson commented on ZOOKEEPER-107: -- As it turns out, I've pretty much implemented Observers in all but name already - they go through the same connection logic as normal followers, and therefore sync, but are disbarred from sending Leader.REQUEST packets to the leader. Similarly, when a leader is sending a proposal packet it only gets sent to those followers which are in the current view. Since the logic is very similar, and we will be able to distinguish observers from followers by whether they are members of the current view, I haven't duplicated code into Observer* classes. I added this when finding that any new follower can join an existing ensemble and issue proposals to it, even if the static configuration of the ensemble does not contain it. This seemed to deadlock the ensemble pretty quickly :) > Allow dynamic changes to server cluster membership > -- > > Key: ZOOKEEPER-107 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Patrick Hunt >Assignee: Henry Robinson > Attachments: SimpleAddition.rtf > > > Currently cluster membership is statically defined, adding/removing hosts > to/from the server cluster dynamically needs to be supported. -- 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 #352
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/352/ -- [...truncated 128534 lines...] [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:911) [junit] 2009-06-20 10:43:27,449 - INFO [NIOServerCxn.Factory:33221:nioservercnxn$fact...@234] - NIOServerCnxn factory exited run method [junit] 2009-06-20 10:43:27,449 - INFO [main:finalrequestproces...@278] - shutdown of request processor complete [junit] 2009-06-20 10:43:27,449 - INFO [ProcessThread:-1:preprequestproces...@119] - PrepRequestProcessor exited loop! [junit] 2009-06-20 10:43:27,449 - INFO [SyncThread:0:syncrequestproces...@134] - SyncRequestProcessor exited! [junit] ensureOnly:[] [junit] 2009-06-20 10:43:27,549 - INFO [main:clientb...@316] - STARTING server [junit] 2009-06-20 10:43:27,549 - INFO [main:zookeeperser...@159] - Created server [junit] 2009-06-20 10:43:27,551 - INFO [main:files...@81] - Reading snapshot http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/ws/trunk/build/test/tmp/test3362828382712010378.junit.dir/version-2/snapshot.5 [junit] 2009-06-20 10:43:27,553 - INFO [main:filetxnsnap...@208] - Snapshotting: 6 [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2009-06-20 10:43:27,555 - INFO [NIOServerCxn.Factory:33221:nioserverc...@690] - Processing stat command from /127.0.0.1:42412 [junit] 2009-06-20 10:43:27,555 - WARN [NIOServerCxn.Factory:33221:nioserverc...@488] - Exception causing close of session 0x0 due to java.io.IOException: Responded to info probe [junit] 2009-06-20 10:43:27,555 - INFO [NIOServerCxn.Factory:33221:nioserverc...@826] - closing session:0x0 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:42412] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2009-06-20 10:43:29,470 - INFO [main-SendThread:clientcnxn$sendthr...@835] - Attempting connection to server /127.0.0.1:33221 [junit] 2009-06-20 10:43:29,470 - INFO [main-SendThread:clientcnxn$sendthr...@751] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:42413 remote=/127.0.0.1:33221] [junit] 2009-06-20 10:43:29,470 - INFO [main-SendThread:clientcnxn$sendthr...@903] - Server connection successful [junit] 2009-06-20 10:43:29,470 - INFO [NIOServerCxn.Factory:33221:nioserverc...@576] - Connected to /127.0.0.1:42413 lastZxid 6 [junit] 2009-06-20 10:43:29,471 - INFO [NIOServerCxn.Factory:33221:nioserverc...@957] - Finished init of 0x121fd42ee13 valid:true [junit] 2009-06-20 10:43:29,471 - INFO [NIOServerCxn.Factory:33221:nioserverc...@604] - Renewing session 0x121fd42ee13 [junit] 2009-06-20 10:43:30,000 - INFO [SessionTracker:sessiontrackeri...@139] - SessionTrackerImpl exited loop! [junit] 2009-06-20 10:43:40,550 - INFO [main:zookee...@437] - Closing session: 0x121fd42ee13 [junit] 2009-06-20 10:43:40,551 - INFO [main:clientc...@1034] - Closing ClientCnxn for session: 0x121fd42ee13 [junit] 2009-06-20 10:43:40,551 - INFO [ProcessThread:-1:preprequestproces...@379] - Processed session termination request for id: 0x121fd42ee13 [junit] 2009-06-20 10:43:40,588 - INFO [SyncThread:0:nioserverc...@826] - closing session:0x121fd42ee13 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:42413] [junit] 2009-06-20 10:43:40,588 - INFO [main-SendThread:clientcnxn$sendthr...@927] - Exception while closing send thread for session 0x121fd42ee13 : Read error rc = -1 java.nio.DirectByteBuffer[pos=0 lim=4 cap=4] [junit] 2009-06-20 10:43:40,688 - INFO [main:clientc...@1020] - Disconnecting ClientCnxn for session: 0x121fd42ee13 [junit] 2009-06-20 10:43:40,688 - INFO [main:zookee...@445] - Session: 0x121fd42ee13 closed [junit] 2009-06-20 10:43:40,688 - INFO [main-EventThread:clientcnxn$eventthr...@487] - EventThread shut down [junit] 2009-06-20 10:43:40,689 - INFO [main:clientb...@332] - tearDown starting [junit] 2009-06-20 10:43:40,689 - INFO [main:clientb...@323] - STOPPING server [junit] 2009-06-20 10:43:40,689 - INFO [NIOServerCxn.Factory:33221:nioservercnxn$fact...@234] - NIOServerCnxn factory exited run method [junit] 2009-06-20 10:43:40,690 - INFO [main:finalrequestproces...@278] - shutdown of request processor complete [junit] 2009-06-20 10:43:40,690 - INFO [ProcessThread:-1:preprequestproces...@119] - PrepRequestProcessor exited loop! [junit] 2009-06-20 10:43:40,690 - INFO [SyncThread:0:syncrequestproces...@134] - SyncRequestProcessor exited! [junit] e
[jira] Commented: (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722153#action_12722153 ] Flavio Paiva Junqueira commented on ZOOKEEPER-107: -- +1, I think it is a good idea to use observers (ZOOKEEPER-368). This way we make sure that once the new configuration is committed the new active member is in sync with the leader. I have a slightly different idea of how to make it work, though. I was thinking that once the observer finsihes synchronizing with the leader, it can simply submit a setData. This way we have no special code path for this operation. Only when finalizing the setData operation we have to update all appropriate data structures. > Allow dynamic changes to server cluster membership > -- > > Key: ZOOKEEPER-107 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Patrick Hunt >Assignee: Henry Robinson > Attachments: SimpleAddition.rtf > > > Currently cluster membership is statically defined, adding/removing hosts > to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-446) some traces of the host auth scheme left
[ https://issues.apache.org/jira/browse/ZOOKEEPER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722148#action_12722148 ] Hadoop QA commented on ZOOKEEPER-446: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12411282/ZOOKEEPER-446.patch against trunk revision 786317. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/127/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/127/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/127/console This message is automatically generated. > some traces of the host auth scheme left > > > Key: ZOOKEEPER-446 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-446 > Project: Zookeeper > Issue Type: Bug >Reporter: Benjamin Reed > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-446.patch > > > the host auth scheme was removed because it used a blocking call in an async > pipeline. however, tragically, the blocking call was not removed including a > couple of other stray classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
