On Fri, Mar 2, 2012 at 3:33 PM, Amirhossein Kiani wrote:
> Oh.. you are right. The value was skipped because I was getting two of
> some values (newer but not older)
> So I should restructure my code to not make decisions that rely on locks
> created based on node data (unless I come up with a way
Oh.. you are right. The value was skipped because I was getting two of some
values (newer but not older)
So I should restructure my code to not make decisions that rely on locks
created based on node data (unless I come up with a way to sync the state
myself :D) I think I'll implement that by cr
Was there ever a JIRA created for this issue ?
Thanks,
Neha
On Fri, Feb 10, 2012 at 9:31 AM, Mahadev Konar wrote:
> Great. You should have the gc logs then. Mind creating a jira and
> uploading to it?
>
> mahadev
>
> 2012/2/10 César Álvarez Núñez :
>> This is the java.env file content.
>>
>> now
I don't think that your test tests what you think it tests.
You won't necessarily get a notification every time a value changes. If a
value changes and a watch is queued, you won't get another notification
until you get the data and set the new watch. If another change happens
before you reset t
I did have an issue in my test, namely not making sure I wait for all the watches to fire. I added a check for that now: https://gist.github.com/1961660, but still the test fails.
test-get-data.tar.gz
Description: GNU Zip compressed data
Amir
On Mar 2, 2012, at 1:58 PM, Amirhossein Kiani wrote:H
Hmm... I tried testing the idea that if I call the getData() on updated node in the watcher's process() method I'll get the updated data.I created a watcher class that keeps track of the values it's receiving and in my test I sequentially set 1 values on the node. I do see that some times I'm g
On Fri, Mar 2, 2012 at 11:23 AM, Amirhossein Kiani wrote:
> Many thanks Patrick for pointing me to the new documentation. I just found
> the other one from Google somehow.
>
No problem.
> So what I think is happening is actually impossible: to do getData() on a
> node and see the OLD data. in
Many thanks Patrick for pointing me to the new documentation. I just found the
other one from Google somehow.
So what I think is happening is actually impossible: to do getData() on a node
and see the OLD data. in other words, I do not need to loop on a getData() to
get the actual new data afte
On Thu, Mar 1, 2012 at 4:11 PM, Amirhossein Kiani wrote:
> Hi ZooKeepers,
Hi Amir.
> I just recently had an issue about getting the a node's updated data after
> the watch was actually fired. Being pretty confused, I read the documentation
> page again and sure enough this has been stated:
>
>
I suggest starting with Curator. It would make a good foundation.
-JZ
On 3/2/12 12:39 AM, "Christopher Schmidt" wrote:
>Hi all, we plan to use Zookeeper and I wonder if there is a Java framework
>out there to use ZK as a central configuration service (holding paths,
>locations, settings or what
Hi all, we plan to use Zookeeper and I wonder if there is a Java framework
out there to use ZK as a central configuration service (holding paths,
locations, settings or what ever)?
regards Christopher
--
Christopher
twitter: @fakod
blog: http://blog.fakod.eu
11 matches
Mail list logo
