Ketan Gangatirkar
2011-05-03, 21:07
Mahadev Konar
2011-05-03, 21:17
Ketan Gangatirkar
2011-05-03, 22:31
Patrick Hunt
2011-05-03, 22:46
Ketan Gangatirkar
2011-05-04, 01:42
Patrick Hunt
2011-05-04, 16:26
Ketan Gangatirkar
2011-05-04, 16:57
Patrick Hunt
2011-05-04, 17:53
Ketan Gangatirkar
2011-05-06, 11:33
Patrick Hunt
2011-05-06, 16:32
Ketan Gangatirkar
2011-05-18, 01:07
Patrick Hunt
2011-05-19, 19:05
Ketan Gangatirkar
2011-05-19, 21:17
Patrick Hunt
2011-05-19, 23:59
Gunnar Wagenknecht
2011-05-05, 21:16
-
observers in occasionally disconnected data centersKetan Gangatirkar 2011-05-03, 21:07
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]
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 2011-05-03, 21:07
-
Re: observers in occasionally disconnected data centersMahadev Konar 2011-05-03, 21:17
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]
>
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]
>
+
Mahadev Konar 2011-05-03, 21:17
-
Re: observers in occasionally disconnected data centersKetan Gangatirkar 2011-05-03, 22:31
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
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 2011-05-03, 22:31
-
Re: observers in occasionally disconnected data centersPatrick Hunt 2011-05-03, 22:46
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
>
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
>
+
Patrick Hunt 2011-05-03, 22:46
-
Re: observers in occasionally disconnected data centersKetan Gangatirkar 2011-05-04, 01:42
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
* 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
+
Ketan Gangatirkar 2011-05-04, 01:42
-
Re: observers in occasionally disconnected data centersPatrick Hunt 2011-05-04, 16:26
Hi Ketan, the patch is failing to apply
https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
Looks like you used git, I usually do something like:
git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
can you give it another try?
Patrick
On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> 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
>
https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
Looks like you used git, I usually do something like:
git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
can you give it another try?
Patrick
On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> 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
>
+
Patrick Hunt 2011-05-04, 16:26
-
Re: observers in occasionally disconnected data centersKetan Gangatirkar 2011-05-04, 16:57
Got the patch formatted right and applying successfully, now I'll see
if I can figure out the unit test failure.
On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Hi Ketan, the patch is failing to apply
> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>
> Looks like you used git, I usually do something like:
> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
> can you give it another try?
>
> Patrick
>
> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> 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
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
if I can figure out the unit test failure.
On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Hi Ketan, the patch is failing to apply
> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>
> Looks like you used git, I usually do something like:
> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
> can you give it another try?
>
> Patrick
>
> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> 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
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
+
Ketan Gangatirkar 2011-05-04, 16:57
-
Re: observers in occasionally disconnected data centersPatrick Hunt 2011-05-04, 17:53
This is odd, it's failing in the c tests but for a weird reason:
in:
https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
it says:
/grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
line 115: java: command not found
I'll ping the hudson admins and see if this is a known issue (also
hudson is very slow today for some reason).
Once that's addressed we should be good to go.
Patrick
On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Got the patch formatted right and applying successfully, now I'll see
> if I can figure out the unit test failure.
>
> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Hi Ketan, the patch is failing to apply
>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>
>> Looks like you used git, I usually do something like:
>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>> can you give it another try?
>>
>> Patrick
>>
>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> 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
in:
https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
it says:
/grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
line 115: java: command not found
I'll ping the hudson admins and see if this is a known issue (also
hudson is very slow today for some reason).
Once that's addressed we should be good to go.
Patrick
On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Got the patch formatted right and applying successfully, now I'll see
> if I can figure out the unit test failure.
>
> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Hi Ketan, the patch is failing to apply
>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>
>> Looks like you used git, I usually do something like:
>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>> can you give it another try?
>>
>> Patrick
>>
>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> 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
+
Patrick Hunt 2011-05-04, 17:53
-
Re: observers in occasionally disconnected data centersKetan Gangatirkar 2011-05-06, 11:33
Hi, Patrick. Were you able to get any assistance from the hudson
admins? Thanks.
On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> This is odd, it's failing in the c tests but for a weird reason:
>
> in:
> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>
> it says:
> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
> line 115: java: command not found
>
> I'll ping the hudson admins and see if this is a known issue (also
> hudson is very slow today for some reason).
>
> Once that's addressed we should be good to go.
>
> Patrick
>
> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> Got the patch formatted right and applying successfully, now I'll see
>> if I can figure out the unit test failure.
>>
>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>> Hi Ketan, the patch is failing to apply
>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>
>>> Looks like you used git, I usually do something like:
>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>> can you give it another try?
>>>
>>> Patrick
>>>
>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>> 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
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
admins? Thanks.
On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> This is odd, it's failing in the c tests but for a weird reason:
>
> in:
> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>
> it says:
> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
> line 115: java: command not found
>
> I'll ping the hudson admins and see if this is a known issue (also
> hudson is very slow today for some reason).
>
> Once that's addressed we should be good to go.
>
> Patrick
>
> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> Got the patch formatted right and applying successfully, now I'll see
>> if I can figure out the unit test failure.
>>
>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>> Hi Ketan, the patch is failing to apply
>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>
>>> Looks like you used git, I usually do something like:
>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>> can you give it another try?
>>>
>>> Patrick
>>>
>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>> 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
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
+
Ketan Gangatirkar 2011-05-06, 11:33
-
Re: observers in occasionally disconnected data centersPatrick Hunt 2011-05-06, 16:32
Mahadev is working with Giri to address. The jenkins folks are saying
this is a machine administered by Yahoo and the issue needs to be
address with them (their admins, but Mahadev/Giri are looking into it
from our (zk) side).
Patrick
On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Hi, Patrick. Were you able to get any assistance from the hudson
> admins? Thanks.
>
> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> This is odd, it's failing in the c tests but for a weird reason:
>>
>> in:
>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>
>> it says:
>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>> line 115: java: command not found
>>
>> I'll ping the hudson admins and see if this is a known issue (also
>> hudson is very slow today for some reason).
>>
>> Once that's addressed we should be good to go.
>>
>> Patrick
>>
>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> Got the patch formatted right and applying successfully, now I'll see
>>> if I can figure out the unit test failure.
>>>
>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>> Hi Ketan, the patch is failing to apply
>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>
>>>> Looks like you used git, I usually do something like:
>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>> can you give it another try?
>>>>
>>>> Patrick
>>>>
>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>> 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.
this is a machine administered by Yahoo and the issue needs to be
address with them (their admins, but Mahadev/Giri are looking into it
from our (zk) side).
Patrick
On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Hi, Patrick. Were you able to get any assistance from the hudson
> admins? Thanks.
>
> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> This is odd, it's failing in the c tests but for a weird reason:
>>
>> in:
>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>
>> it says:
>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>> line 115: java: command not found
>>
>> I'll ping the hudson admins and see if this is a known issue (also
>> hudson is very slow today for some reason).
>>
>> Once that's addressed we should be good to go.
>>
>> Patrick
>>
>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> Got the patch formatted right and applying successfully, now I'll see
>>> if I can figure out the unit test failure.
>>>
>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>> Hi Ketan, the patch is failing to apply
>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>
>>>> Looks like you used git, I usually do something like:
>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>> can you give it another try?
>>>>
>>>> Patrick
>>>>
>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>> 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.
+
Patrick Hunt 2011-05-06, 16:32
-
Re: observers in occasionally disconnected data centersKetan Gangatirkar 2011-05-18, 01:07
Hi. Has there been any progress on this? Thanks.
On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Mahadev is working with Giri to address. The jenkins folks are saying
> this is a machine administered by Yahoo and the issue needs to be
> address with them (their admins, but Mahadev/Giri are looking into it
> from our (zk) side).
>
> Patrick
>
> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> Hi, Patrick. Were you able to get any assistance from the hudson
>> admins? Thanks.
>>
>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>> This is odd, it's failing in the c tests but for a weird reason:
>>>
>>> in:
>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>
>>> it says:
>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>> line 115: java: command not found
>>>
>>> I'll ping the hudson admins and see if this is a known issue (also
>>> hudson is very slow today for some reason).
>>>
>>> Once that's addressed we should be good to go.
>>>
>>> Patrick
>>>
>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>> Got the patch formatted right and applying successfully, now I'll see
>>>> if I can figure out the unit test failure.
>>>>
>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>> Hi Ketan, the patch is failing to apply
>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>
>>>>> Looks like you used git, I usually do something like:
>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>> can you give it another try?
>>>>>
>>>>> Patrick
>>>>>
>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>> 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:
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Mahadev is working with Giri to address. The jenkins folks are saying
> this is a machine administered by Yahoo and the issue needs to be
> address with them (their admins, but Mahadev/Giri are looking into it
> from our (zk) side).
>
> Patrick
>
> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> Hi, Patrick. Were you able to get any assistance from the hudson
>> admins? Thanks.
>>
>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>> This is odd, it's failing in the c tests but for a weird reason:
>>>
>>> in:
>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>
>>> it says:
>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>> line 115: java: command not found
>>>
>>> I'll ping the hudson admins and see if this is a known issue (also
>>> hudson is very slow today for some reason).
>>>
>>> Once that's addressed we should be good to go.
>>>
>>> Patrick
>>>
>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>> Got the patch formatted right and applying successfully, now I'll see
>>>> if I can figure out the unit test failure.
>>>>
>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>> Hi Ketan, the patch is failing to apply
>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>
>>>>> Looks like you used git, I usually do something like:
>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>> can you give it another try?
>>>>>
>>>>> Patrick
>>>>>
>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>> 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:
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
+
Ketan Gangatirkar 2011-05-18, 01:07
-
Re: observers in occasionally disconnected data centersPatrick Hunt 2011-05-19, 19:05
Hi Ketan, sorry about this. A number of build folks have looked but
can't seem to figure out what's wrong on some of these build hosts.
Running "java" just fails for no reason.
Nigel and I spent part of the day yesterday looking into this with no
luck. For the time being I've pinned the job down to hadoop9 (where
java seems to be picked up fine). You should see a report come through
shortly.
Feel free to reach out to me personally wrt finalizing this issue.
Patrick
On Tue, May 17, 2011 at 6:07 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Hi. Has there been any progress on this? Thanks.
>
> On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Mahadev is working with Giri to address. The jenkins folks are saying
>> this is a machine administered by Yahoo and the issue needs to be
>> address with them (their admins, but Mahadev/Giri are looking into it
>> from our (zk) side).
>>
>> Patrick
>>
>> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> Hi, Patrick. Were you able to get any assistance from the hudson
>>> admins? Thanks.
>>>
>>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>> This is odd, it's failing in the c tests but for a weird reason:
>>>>
>>>> in:
>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>>
>>>> it says:
>>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>>> line 115: java: command not found
>>>>
>>>> I'll ping the hudson admins and see if this is a known issue (also
>>>> hudson is very slow today for some reason).
>>>>
>>>> Once that's addressed we should be good to go.
>>>>
>>>> Patrick
>>>>
>>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>> Got the patch formatted right and applying successfully, now I'll see
>>>>> if I can figure out the unit test failure.
>>>>>
>>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>> Hi Ketan, the patch is failing to apply
>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>>
>>>>>> Looks like you used git, I usually do something like:
>>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>>> can you give it another try?
>>>>>>
>>>>>> Patrick
>>>>>>
>>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>> 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
can't seem to figure out what's wrong on some of these build hosts.
Running "java" just fails for no reason.
Nigel and I spent part of the day yesterday looking into this with no
luck. For the time being I've pinned the job down to hadoop9 (where
java seems to be picked up fine). You should see a report come through
shortly.
Feel free to reach out to me personally wrt finalizing this issue.
Patrick
On Tue, May 17, 2011 at 6:07 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Hi. Has there been any progress on this? Thanks.
>
> On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Mahadev is working with Giri to address. The jenkins folks are saying
>> this is a machine administered by Yahoo and the issue needs to be
>> address with them (their admins, but Mahadev/Giri are looking into it
>> from our (zk) side).
>>
>> Patrick
>>
>> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> Hi, Patrick. Were you able to get any assistance from the hudson
>>> admins? Thanks.
>>>
>>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>> This is odd, it's failing in the c tests but for a weird reason:
>>>>
>>>> in:
>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>>
>>>> it says:
>>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>>> line 115: java: command not found
>>>>
>>>> I'll ping the hudson admins and see if this is a known issue (also
>>>> hudson is very slow today for some reason).
>>>>
>>>> Once that's addressed we should be good to go.
>>>>
>>>> Patrick
>>>>
>>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>> Got the patch formatted right and applying successfully, now I'll see
>>>>> if I can figure out the unit test failure.
>>>>>
>>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>> Hi Ketan, the patch is failing to apply
>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>>
>>>>>> Looks like you used git, I usually do something like:
>>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>>> can you give it another try?
>>>>>>
>>>>>> Patrick
>>>>>>
>>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>> 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
+
Patrick Hunt 2011-05-19, 19:05
-
Re: observers in occasionally disconnected data centersKetan Gangatirkar 2011-05-19, 21:17
Good news: the patch build ran successfully and gave every check a +1.
What's next to get this into trunk?
On Thu, May 19, 2011 at 2:05 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Hi Ketan, sorry about this. A number of build folks have looked but
> can't seem to figure out what's wrong on some of these build hosts.
> Running "java" just fails for no reason.
>
> Nigel and I spent part of the day yesterday looking into this with no
> luck. For the time being I've pinned the job down to hadoop9 (where
> java seems to be picked up fine). You should see a report come through
> shortly.
>
> Feel free to reach out to me personally wrt finalizing this issue.
>
> Patrick
>
> On Tue, May 17, 2011 at 6:07 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> Hi. Has there been any progress on this? Thanks.
>>
>> On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>> Mahadev is working with Giri to address. The jenkins folks are saying
>>> this is a machine administered by Yahoo and the issue needs to be
>>> address with them (their admins, but Mahadev/Giri are looking into it
>>> from our (zk) side).
>>>
>>> Patrick
>>>
>>> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>> Hi, Patrick. Were you able to get any assistance from the hudson
>>>> admins? Thanks.
>>>>
>>>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>> This is odd, it's failing in the c tests but for a weird reason:
>>>>>
>>>>> in:
>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>>>
>>>>> it says:
>>>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>>>> line 115: java: command not found
>>>>>
>>>>> I'll ping the hudson admins and see if this is a known issue (also
>>>>> hudson is very slow today for some reason).
>>>>>
>>>>> Once that's addressed we should be good to go.
>>>>>
>>>>> Patrick
>>>>>
>>>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>> Got the patch formatted right and applying successfully, now I'll see
>>>>>> if I can figure out the unit test failure.
>>>>>>
>>>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>>> Hi Ketan, the patch is failing to apply
>>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>>>
>>>>>>> Looks like you used git, I usually do something like:
>>>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>>>> can you give it another try?
>>>>>>>
>>>>>>> Patrick
>>>>>>>
>>>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>>> 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.
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
What's next to get this into trunk?
On Thu, May 19, 2011 at 2:05 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Hi Ketan, sorry about this. A number of build folks have looked but
> can't seem to figure out what's wrong on some of these build hosts.
> Running "java" just fails for no reason.
>
> Nigel and I spent part of the day yesterday looking into this with no
> luck. For the time being I've pinned the job down to hadoop9 (where
> java seems to be picked up fine). You should see a report come through
> shortly.
>
> Feel free to reach out to me personally wrt finalizing this issue.
>
> Patrick
>
> On Tue, May 17, 2011 at 6:07 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>> Hi. Has there been any progress on this? Thanks.
>>
>> On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>> Mahadev is working with Giri to address. The jenkins folks are saying
>>> this is a machine administered by Yahoo and the issue needs to be
>>> address with them (their admins, but Mahadev/Giri are looking into it
>>> from our (zk) side).
>>>
>>> Patrick
>>>
>>> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>> Hi, Patrick. Were you able to get any assistance from the hudson
>>>> admins? Thanks.
>>>>
>>>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>> This is odd, it's failing in the c tests but for a weird reason:
>>>>>
>>>>> in:
>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>>>
>>>>> it says:
>>>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>>>> line 115: java: command not found
>>>>>
>>>>> I'll ping the hudson admins and see if this is a known issue (also
>>>>> hudson is very slow today for some reason).
>>>>>
>>>>> Once that's addressed we should be good to go.
>>>>>
>>>>> Patrick
>>>>>
>>>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>> Got the patch formatted right and applying successfully, now I'll see
>>>>>> if I can figure out the unit test failure.
>>>>>>
>>>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>>> Hi Ketan, the patch is failing to apply
>>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>>>
>>>>>>> Looks like you used git, I usually do something like:
>>>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>>>> can you give it another try?
>>>>>>>
>>>>>>> Patrick
>>>>>>>
>>>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>>> 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.
Ketan Gangatirkar
[EMAIL PROTECTED]
Perishable Developer
+
Ketan Gangatirkar 2011-05-19, 21:17
-
Re: observers in occasionally disconnected data centersPatrick Hunt 2011-05-19, 23:59
Henry just committed this to trunk. Thanks everyone -- esp Sergey!
Patrick
On Thu, May 19, 2011 at 2:17 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Good news: the patch build ran successfully and gave every check a +1.
> What's next to get this into trunk?
>
> On Thu, May 19, 2011 at 2:05 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Hi Ketan, sorry about this. A number of build folks have looked but
>> can't seem to figure out what's wrong on some of these build hosts.
>> Running "java" just fails for no reason.
>>
>> Nigel and I spent part of the day yesterday looking into this with no
>> luck. For the time being I've pinned the job down to hadoop9 (where
>> java seems to be picked up fine). You should see a report come through
>> shortly.
>>
>> Feel free to reach out to me personally wrt finalizing this issue.
>>
>> Patrick
>>
>> On Tue, May 17, 2011 at 6:07 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> Hi. Has there been any progress on this? Thanks.
>>>
>>> On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>> Mahadev is working with Giri to address. The jenkins folks are saying
>>>> this is a machine administered by Yahoo and the issue needs to be
>>>> address with them (their admins, but Mahadev/Giri are looking into it
>>>> from our (zk) side).
>>>>
>>>> Patrick
>>>>
>>>> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>> Hi, Patrick. Were you able to get any assistance from the hudson
>>>>> admins? Thanks.
>>>>>
>>>>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>> This is odd, it's failing in the c tests but for a weird reason:
>>>>>>
>>>>>> in:
>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>>>>
>>>>>> it says:
>>>>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>>>>> line 115: java: command not found
>>>>>>
>>>>>> I'll ping the hudson admins and see if this is a known issue (also
>>>>>> hudson is very slow today for some reason).
>>>>>>
>>>>>> Once that's addressed we should be good to go.
>>>>>>
>>>>>> Patrick
>>>>>>
>>>>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>> Got the patch formatted right and applying successfully, now I'll see
>>>>>>> if I can figure out the unit test failure.
>>>>>>>
>>>>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>>>> Hi Ketan, the patch is failing to apply
>>>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>>>>
>>>>>>>> Looks like you used git, I usually do something like:
>>>>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>>>>> can you give it another try?
>>>>>>>>
>>>>>>>> Patrick
>>>>>>>>
>>>>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>>>> 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 Thu, May 19, 2011 at 2:17 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
> Good news: the patch build ran successfully and gave every check a +1.
> What's next to get this into trunk?
>
> On Thu, May 19, 2011 at 2:05 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Hi Ketan, sorry about this. A number of build folks have looked but
>> can't seem to figure out what's wrong on some of these build hosts.
>> Running "java" just fails for no reason.
>>
>> Nigel and I spent part of the day yesterday looking into this with no
>> luck. For the time being I've pinned the job down to hadoop9 (where
>> java seems to be picked up fine). You should see a report come through
>> shortly.
>>
>> Feel free to reach out to me personally wrt finalizing this issue.
>>
>> Patrick
>>
>> On Tue, May 17, 2011 at 6:07 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>> Hi. Has there been any progress on this? Thanks.
>>>
>>> On Fri, May 6, 2011 at 11:32 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>> Mahadev is working with Giri to address. The jenkins folks are saying
>>>> this is a machine administered by Yahoo and the issue needs to be
>>>> address with them (their admins, but Mahadev/Giri are looking into it
>>>> from our (zk) side).
>>>>
>>>> Patrick
>>>>
>>>> On Fri, May 6, 2011 at 4:33 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>> Hi, Patrick. Were you able to get any assistance from the hudson
>>>>> admins? Thanks.
>>>>>
>>>>> On Wed, May 4, 2011 at 12:53 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>> This is odd, it's failing in the c tests but for a weird reason:
>>>>>>
>>>>>> in:
>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/247/artifact/trunk/build/tmp/zk.log
>>>>>>
>>>>>> it says:
>>>>>> /grid/0/hudson/hudson-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/zkServer.sh:
>>>>>> line 115: java: command not found
>>>>>>
>>>>>> I'll ping the hudson admins and see if this is a known issue (also
>>>>>> hudson is very slow today for some reason).
>>>>>>
>>>>>> Once that's addressed we should be good to go.
>>>>>>
>>>>>> Patrick
>>>>>>
>>>>>> On Wed, May 4, 2011 at 9:57 AM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>> Got the patch formatted right and applying successfully, now I'll see
>>>>>>> if I can figure out the unit test failure.
>>>>>>>
>>>>>>> On Wed, May 4, 2011 at 11:26 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>>>>>>>> Hi Ketan, the patch is failing to apply
>>>>>>>> https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/246//console
>>>>>>>>
>>>>>>>> Looks like you used git, I usually do something like:
>>>>>>>> git diff rev1..rev2 --no-prefix > ZOOKEEPER-784.patch
>>>>>>>> can you give it another try?
>>>>>>>>
>>>>>>>> Patrick
>>>>>>>>
>>>>>>>> On Tue, May 3, 2011 at 6:42 PM, Ketan Gangatirkar <[EMAIL PROTECTED]> wrote:
>>>>>>>>> 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 Hunt 2011-05-19, 23:59
-
Re: observers in occasionally disconnected data centersGunnar Wagenknecht 2011-05-05, 21:16
Am 03.05.2011 23:07, schrieb Ketan Gangatirkar:
> 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.
Have a look at:
https://issues.apache.org/jira/browse/ZOOKEEPER-892
-Gunnar
--
Gunnar Wagenknecht
[EMAIL PROTECTED]
http://wagenknecht.org/
> 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.
Have a look at:
https://issues.apache.org/jira/browse/ZOOKEEPER-892
-Gunnar
--
Gunnar Wagenknecht
[EMAIL PROTECTED]
http://wagenknecht.org/
+
Gunnar Wagenknecht 2011-05-05, 21:16
