[jira] Commented: (ZOOKEEPER-30) Hooks for atomic broadcast protocol
[ https://issues.apache.org/jira/browse/ZOOKEEPER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694042#action_12694042 ] Flavio Paiva Junqueira commented on ZOOKEEPER-30: - Andrew, It would be really good for us to see a preliminary patch, just to have an idea of how you have implemented a few things. Although perhaps not exactly appropriate, Ben and I had a discussion offline about having or not propose returning a zxid. Currently, only the leader proposes, since broadcast messages are requests transformed into idempotent transactions. If we follow this model, then returning a zxid is not a problem because the leader is the one generating a zxid and a propose call does not block in this case. I understand, however, that you are interested in having Zab in such a way that any process in the ensemble can propose. If any process can propose, then it might not make sense to have a call to propose returning a zxid. The problem of not returning a zxid is that currently the broadcast layer and the application layer are tightly coupled and separating them creates a potential problem for generating snapshots that we use to recover or bring a new follower up to speed. In a little more detail, if we separate the state from the atomic broadcast and return no zxid, then the service layer on top of zab will have no such a notion of transaction identifiers. We currently use such identifiers to generate and guarantee a consistent state transfer. Hooks for atomic broadcast protocol --- Key: ZOOKEEPER-30 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-30 Project: Zookeeper Issue Type: New Feature Components: quorum Reporter: Patrick Hunt Assignee: Mahadev konar Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1938788group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-344) doIO in NioServerCnxn: Exception causing close of session : cause is read error
[
https://issues.apache.org/jira/browse/ZOOKEEPER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694060#action_12694060
]
bryan thompson commented on ZOOKEEPER-344:
--
Here are some more stack traces with DEBUG on the server and the client for
this issue. The configuration, etc. is the same. Logs were written onto an
NFS share but the machines are synched with ntpd.
There are two distinct periods reported here. One leads to a warning on the
server but not to an expired session while the other issues the same warning on
the server and leads to an expired session.
Here is a ping for sessionid 0x120597b6137000b shortly before the warning.
DEBUG [SyncThread:0]
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:74)
2009-03-30 17:34:33,643 - Processing request:: sessionid:0x120597b6137000b
type:ping cxid:0xfffe zxid:0xfffe txntype:unknown n/a
DEBUG [SyncThread:0]
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:137)
2009-03-30 17:34:33,643 - sessionid:0x120597b6137000b type:ping
cxid:0xfffe zxid:0xfffe txntype:unknown n/a
DEBUG [main-SendThread]
org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:548)
2009-03-30 17:34:33,643 - Got ping response for sessionid:0x120597b6137000b
after 1ms
Here is the Exception causing close of session.
WARN [main-SendThread]
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:898) 2009-03-30
17:34:48,120 - Exception closing session 0x120597b6137000b to
sun.nio.ch.selectionkeyi...@7eb1cc87
java.io.IOException: TIMED OUT
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:837)
WARN [NIOServerCxn.Factory:2181]
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:417)
2009-03-30 17:34:48,166 - Exception causing close of session 0x120597b6137000b
due to java.io.IOException: Read error
DEBUG [NIOServerCxn.Factory:2181]
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:420)
2009-03-30 17:34:48,166 - IOException stack trace
java.io.IOException: Read error
at
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:295)
at
org.apache.zookeeper.server.NIOServerCnxn$Factory.run(NIOServerCnxn.java:162)
INFO [NIOServerCxn.Factory:2181]
org.apache.zookeeper.server.NIOServerCnxn.close(NIOServerCnxn.java:752)
2009-03-30 17:34:48,172 - closing session:0x120597b6137000b NIOServerCnxn:
java.nio.channels.SocketChannel[connected local=/192.168.6.21:2181
remote=/192.168.6.28:60720]
And here is appears that the closed session was re-initialized? Perhaps closed
!= expired?
INFO [NIOServerCxn.Factory:2181]
org.apache.zookeeper.server.NIOServerCnxn.finishSessionInit(NIOServerCnxn.java:881)
2009-03-30 17:34:50,111 - Finished init of 0x120597b6137000b valid:true
INFO [NIOServerCxn.Factory:2181]
org.apache.zookeeper.server.NIOServerCnxn.readConnectRequest(NIOServerCnxn.java:531)
2009-03-30 17:34:50,111 - Renewing session 0x120597b6137000b
DEBUG [SyncThread:0]
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:74)
2009-03-30 17:34:50,112 - Processing request:: sessionid:0x120597b6137000b
type:setWatches cxid:0xfff8 zxid:0xfffe txntype:unknown
DEBUG [SyncThread:0]
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:137)
2009-03-30 17:34:50,112 - sessionid:0x120597b6137000b type:setWatches
cxid:0xfff8 zxid:0xfffe txntype:unknown
DEBUG [SyncThread:0]
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:74)
2009-03-30 17:34:50,121 - Processing request:: sessionid:0x120597b6137000b
type:create cxid:0x8 zxid:0xb95 txntype:-1 n/a
DEBUG [main-SendThread]
org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:610)
2009-03-30 17:34:50,126 - Reading reply sessionid:0x120597b6137000b, packet::
path:null finished:false header:: -8,101 replyHeader:: -8,2964,0 request::
2964,v{},v{'/benchmark/config/com.bigdata.service.jini.DataServer/logicalService11/masterElection_INVALID},v{}
response:: null
Another trace that leads to an expired session:
DEBUG [SyncThread:0]
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:74)
2009-03-30 18:35:39,478 - Processing request:: sessionid:0x120597b61370008
type:ping cxid:0xfffe zxid:0xfffe txntype:unknown n/a
DEBUG [SyncThread:0]
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:137)
2009-03-30 18:35:39,478 - sessionid:0x120597b61370008 type:ping
cxid:0xfffe zxid:0xfffe txntype:unknown n/a
DEBUG [main-SendThread]
[jira] Commented: (ZOOKEEPER-349) to automate patch testing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694100#action_12694100 ] Hudson commented on ZOOKEEPER-349: -- Integrated in ZooKeeper-trunk #267 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/267/]) . to automate patch testing. (giridharan kesavan via mahadev) to automate patch testing -- Key: ZOOKEEPER-349 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-349 Project: Zookeeper Issue Type: Improvement Components: build 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-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-29: Attachment: ZOOKEEPER-29.patch This is a preliminary patch. It is not functional, but it gives an idea of what I'm trying to do, so please comment if you have a chance to check it out. Flexible quorums Key: ZOOKEEPER-29 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-29 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Attachments: ZOOKEEPER-29.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1938782group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-78: --- Attachment: ZOOKEEPER-78.patch this patch has the c library in it as well. Now I think of it, I probably should have done it in a seperate jira with subtasks as java and c libraries. - added the c library with auto * files to create teh library - added cpp unit testing for the c library - similar to java interface, the c interface also allows a callback method to be called in case of lock being avquired and released. - i will be cleaning up the patch (with some more docs and rmeocing unneccasry printf's and unused code). comments are welcome... added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation --- Key: ZOOKEEPER-78 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 Project: Zookeeper Issue Type: New Feature Components: java client Affects Versions: 3.0.0 Reporter: james strachan Assignee: james strachan Fix For: 3.2.0 Attachments: patch_with_including_Benjamin's_fix.patch, using_zookeeper_facade.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch Here's a patch which adds a little WriteLock helper class for performing leader elections or creating exclusive locks in some directory znode. Note its an early cut; am sure we can improve it over time. The aim is to avoid folks having to use the low level ZK stuff but provide a simpler high level abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-78: --- Attachment: (was: ZOOKEEPER-78.patch) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation --- Key: ZOOKEEPER-78 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 Project: Zookeeper Issue Type: New Feature Components: java client Affects Versions: 3.0.0 Reporter: james strachan Assignee: james strachan Fix For: 3.2.0 Attachments: patch_with_including_Benjamin's_fix.patch, using_zookeeper_facade.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch Here's a patch which adds a little WriteLock helper class for performing leader elections or creating exclusive locks in some directory znode. Note its an early cut; am sure we can improve it over time. The aim is to avoid folks having to use the low level ZK stuff but provide a simpler high level abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694348#action_12694348 ] Mahadev konar commented on ZOOKEEPER-78: make sure that you download the patch adn then view it. I tried opening up the patch in the browser and it fails. It thinks that the file is xml (not sure why.. ) and tried opening it as an xml file... added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation --- Key: ZOOKEEPER-78 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 Project: Zookeeper Issue Type: New Feature Components: java client Affects Versions: 3.0.0 Reporter: james strachan Assignee: james strachan Fix For: 3.2.0 Attachments: patch_with_including_Benjamin's_fix.patch, using_zookeeper_facade.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch Here's a patch which adds a little WriteLock helper class for performing leader elections or creating exclusive locks in some directory znode. Note its an early cut; am sure we can improve it over time. The aim is to avoid folks having to use the low level ZK stuff but provide a simpler high level abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-357) ZooKeeper cannot actually take care of a Zoo
ZooKeeper cannot actually take care of a Zoo Key: ZOOKEEPER-357 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-357 Project: Zookeeper Issue Type: Bug Reporter: Benjamin Reed Priority: Critical Last week I setup an unattended ZooKeeper cluster that I expected to be able to take care of things while I was on vacation. I used 7 dedicated servers with two disks. I had done extensive burn in testing of the servers, so I fully expected the system to work problem free for the entire week. Indeed, when I returned yesterday none of the 7 servers had any hardware or software problem the entire time nor had there been any network problems. On the other hand the Zoo was in complete chaos. Even though there were no errors in the ZooKeeper log most of the animals were near starvation, except for the lions who had gotten loose and eaten some of the pigs. I'll not even go into the stench from the dirty cages! Either the documentation needs to more clearly explain how to configure the server properly in the Zoo environment, or it should clearly state that ZooKeeper cannot take care of the Zoo out of the box! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-357) ZooKeeper cannot actually take care of a Zoo
[ https://issues.apache.org/jira/browse/ZOOKEEPER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694401#action_12694401 ] Mahadev konar commented on ZOOKEEPER-357: - ben, is this is an april fool's joke? ZooKeeper cannot actually take care of a Zoo Key: ZOOKEEPER-357 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-357 Project: Zookeeper Issue Type: Bug Reporter: Benjamin Reed Priority: Critical Last week I setup an unattended ZooKeeper cluster that I expected to be able to take care of things while I was on vacation. I used 7 dedicated servers with two disks. I had done extensive burn in testing of the servers, so I fully expected the system to work problem free for the entire week. Indeed, when I returned yesterday none of the 7 servers had any hardware or software problem the entire time nor had there been any network problems. On the other hand the Zoo was in complete chaos. Even though there were no errors in the ZooKeeper log most of the animals were near starvation, except for the lions who had gotten loose and eaten some of the pigs. I'll not even go into the stench from the dirty cages! Either the documentation needs to more clearly explain how to configure the server properly in the Zoo environment, or it should clearly state that ZooKeeper cannot take care of the Zoo out of the box! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
