CODEWITHSUNDEEP
javaapache-zookeeperapache-curator
user3927415
user3927415

Reputation: 435

watch multiple nodes on zookeeper with multithreaded system

I have a project which I watch several nodes in several different threads. Now, I noticed that when I watch a node, and it changed, and an event is raised, the watch on a certain node (called A for example) blocks all the other watchers. So only after the watcher on A is finished , the other watcher will return to watch the nodes changes. Meaning, if a node is changed (called B for example) while its watcher is blocked, only after the watcher on A is finished, the watcher on node B will raise the event.

This problem causes the application be slower.

So, in order to fix this, I wanted to use a different client connnection for each thread, (using curator), but I have read that one connection should be enough, and if I need more than one, there is something worng with my implementation.

1) I dont understand what is the problem with multiple connection to zookeeper server

2) Is there another solution for my problem?

Edit - more specific about the problem

I have a master which gets requests from clients ( and each clients can save files on my server and we do some process on this file, it is more complex than it sounds, i wont elaborate it), and the master creates a node in /tasks/ for a worker to process the file (without its data of course, the data is in a db). When the worker watches his node, he processes the file, and when he finishes, he creates a node in /status (which has all the files that their process were finished). The master watches the node /status , and when something was changed , it gets the children, and creates a thread (in order to make all faster, because zookeeper watchers and callbacks are single threaded ), which will release those files (remove some meta from db, return a response to client, remove some variable etc.).

That is one of the main flows, but I have another important parts of the code which listen on nodes, and process their children when there are changes.

Because this thing is in a thread, I created a list of the nodes that were finished already, so I wont do the final process more than once, but it was more complex than that, and that solution caused other problems, some concurrency bugs.

So as i asked

1) What is the problem with multiple connection , for each important flow, so i wont have to create threades inside watches and callback?

2) Is there another solution i can use here?

Upvotes: 0

Views: 2701

Answers (1)

Randgalt
Randgalt

Reputation: 2956

It's not well documented, but ZooKeeper has a single thread for handling watchers and async callbacks. We wrote a tech note for Curator about it. https://cwiki.apache.org/confluence/display/CURATOR/TN1

Upvotes: 1

Related Questions