Correct way of using Double Barries

[akiani]

(moved from ZooKeeper users mailing list)

Dear JZ,

I am curious to know how DistributedDoubleBarries can be correctly used in the same JVM. I basically want to sync the start and end of an execution inside a DistributedQueue's consume method and a Listener call for a PathChildrenCache.

I would truly appreciate an example snippet.

Cheers,
Amir

[akiani]

Also, I'd be very interested to know how I can use an Executor for a PathChildrenCache.

[akiani]

Additionally, it seems like that during the consumeMessage of the DistributedQueue, all other watchers are blocked and no other watch fires before that method has left.

[Randgalt]

A quick glance suggests that the QueueConsumer/Executor mechanism is broken in DistributedQueue. I'll work on a fix for that and open a separate issue.

#38

[akiani]

Thanks Jordan!

[Randgalt]

All the listeners in Curator are implemented using a ListenerContainer. The addListener() method has two versions. The first takes only the listener instance. The second takes the listener instance and an Executor. So, if you want your listener to be called in a different thread:

ExecutorService executor = Executors.newSingleThreadExecutor(); // an example thread pool
cache.getListenable().addListener(myListener, myExecutor);

You don't have to use a thread pool for the Executor. Use whatever works for your app.

[Randgalt]

I am curious to know how DistributedDoubleBarries can be correctly used in the same JVM.

Allocate a new DistributedDoubleBarrier instance for each thread that needs to be part of the barrier using the same barrierPath.

[akiani]

Thanks Jordan. I think I have verified that when the thread waits for the DoubleBarrier in QueueConsumer, other watches in my app are blocked.

Do you think if I use a different CuratorFramework for each of my objects it could help resolving this problem?

[Randgalt]

I see - so you have a QueueConsumer. When the consumer gets notified of a message it uses a DoubleBarrier. Can you write an example that exposes the problem?

[akiani]

Sure. I'll work on an example project. It'll be a bit involved but I guess it's worth doing it to make sure that is actually the problem.

Also, for leader election, do I have to do a Thread.currentThread().join() at the end of takeLeadership() like you have done in the tests? It seems like the leadership is passed on to the next Participant if I don't do so.

[Randgalt]

Sure. I'll work on an example project. It'll be a bit involved but I guess it's worth doing it to make sure that is actually the problem.

That will be necessary. I took a look at the code and see no reason why you should be getting the behavior your seeing. BTW - why are you using a Barrier?

[Randgalt]

Also, for leader election, do I have to do a Thread.currentThread().join() at the end of takeLeadership() like you have done in the tests? It seems like the leadership is passed on to the next Participant if I don't do so.

takeLeadership() should only exit if you no longer want to be the leader. Thread.join() wouldn't be correct as you'd never exit.

[akiani]

But that's what I want. I want to stay the leader unless my sever dies. What would be the alternative way?

[Randgalt]

OK - then sure Thread.join().

[akiani]

Oh! I found out what the issue was after trying to create the test case!
I was creating the PathChildrenCache for a non-existing node at the beginning. I was later creating the node that the Cache was watching on during the call for creating the first child. Somehow this wont trigger the watch on the path!

I think the PathChildrenCache should check for existence of the path and error out if it doesn't to prevent future confusion.

Thanks a lot! :)

[Randgalt]

This is addressed by #34 and will be in the next release.

[akiani]

Oh cool. Thanks Jordan for your help. I think I'm good to go for now :)

Amir

On Mar 6, 2012, at 2:19 PM, Jordan Zimmerman wrote:

This is addressed by #34 and will be in the next release.

---

Reply to this email directly or view it on GitHub:
#37 (comment)