I have updated Sergey's patch to: * apply to current trunk * incorporate one trivial output change he made to StatCommand in NettyServerCnxn.java * change log4j references to slf4j
I have successfully run ant releaseaudit on the result. The updated patch is now attached to the issue: https://issues.apache.org/jira/browse/ZOOKEEPER-784 I do *not* make any claim to have understood the contents of this patch; all I did was synch everything and fix the obvious log4j/slf4j change. Now what? On Tue, May 3, 2011 at 5:46 PM, Patrick Hunt <[email protected]> wrote: > The core tests failed on last hudson, I just kicked off a patch build, > seems recent changes (logging?) have caused the patch to stop > applying: > https://hudson.apache.org/hudson/view/S-Z/view/ZooKeeper/job/PreCommit-ZOOKEEPER-Build/238/console > > Ketan would you like to try updating the patch and resubmit? > > Patrick > > On Tue, May 3, 2011 at 3:31 PM, Ketan Gangatirkar <[email protected]> wrote: >> Thanks, Mahadev. I had seen ZOOKEEPER-892 but not ZOOKEEPER-784. The >> latter may be what we need. >> >> I read the comments attached to that issue. The most recent comment >> was a Hudson CI message indicating that the tests against the patch >> failed. I was not able to find out more as it appears that the >> configuration of the Apache Hudson has changed. It appears that the >> patch was approved but not merged into trunk, and it's now in limbo. >> What is necessary to get that feature into the next release? I may be >> able to assist, depending on what's involved. Thank you. >> >> >> On Tue, May 3, 2011 at 4:17 PM, Mahadev Konar <[email protected]> wrote: >>> Hi Ketan, >>> You are correct that observers need connection to quorum as well. >>> There have been quite a few discussions on multi colo replication and >>> read only mode of ZooKeeper. >>> >>> Here are the jiras for those: >>> >>> https://issues.apache.org/jira/browse/ZOOKEEPER-784 >>> and >>> https://issues.apache.org/jira/browse/ZOOKEEPER-892 >>> >>> These have been mostly targeted at exactly a use case like yours. >>> Please take a look and them and feel free to contribute/comment on the >>> jiras. >>> >>> -- >>> thanks >>> mahadev >>> @mahadevkonar >>> >>> >>> >>> On Tue, May 3, 2011 at 2:07 PM, Ketan Gangatirkar <[email protected]> wrote: >>>> Hi. We're considering ZooKeeper for coordinating operations across >>>> multiple data centers. These data centers will occasionally be >>>> disconnected. We were planning on using observers in remote data >>>> centers. Our applications can survive being unable to *write* to >>>> ZooKeeper, but they do need to be able to read from it, even if the >>>> data were stale. >>>> >>>> On further examination, it looks like observers must always be >>>> connected to the quorum to function at all. Is this correct? Does >>>> anyone have suggestions for how to work around this problem? The >>>> first thing that comes to mind is duplicating the required data in >>>> some other local data store and falling back on that when the DC >>>> becomes disconnected. I imagine the disadvantages of that are obvious >>>> to everyone. I hope someone can share some great idea that allows me >>>> to avoid that miserable fate. Thanks. >>>> >>>> -- >>>> Ketan Gangatirkar >>>> [email protected] >>>> >>> >> >> >> >> -- >> Ketan Gangatirkar >> [email protected] >> Perishable Developer >> > -- Ketan Gangatirkar [email protected] Perishable Developer
