У меня есть проект, который я наблюдаю за несколькими узлами в нескольких разных потоках. Теперь я заметил, что когда я наблюдаю за узлом, и он меняется, и возникает событие, наблюдение за определенным узлом (например, под названием A) блокирует всех других наблюдателей. Таким образом, только после того, как наблюдатель на А закончен, другой наблюдатель вернется, чтобы наблюдать за изменениями узлов. Это означает, что если узел изменен (например, называется B), когда его наблюдатель заблокирован, то только после завершения наблюдателя на A наблюдатель на узле B вызовет событие.
Эта проблема приводит к замедлению работы приложения.
Итак, чтобы исправить это, я хотел использовать разные клиентские соединения для каждого потока (используя куратор), но я прочитал, что одного соединения должно быть достаточно, и если мне нужно больше одного, есть что-то Работа с моей реализацией.
1) Я не понимаю, в чем проблема с множественным подключением к серверу zookeeper
2) Есть ли другое решение для моей проблемы?
Редактировать - более конкретно о проблеме
У меня есть мастер, который получает запросы от клиентов (и каждый клиент может сохранять файлы на моем сервере, и мы выполняем некоторый процесс над этим файлом, он более сложный, чем кажется, я не буду его разрабатывать), и мастер создает узел в / tasks / для работника для обработки файла (без данных, конечно, данные находятся в БД). Когда рабочий наблюдает за своим узлом, он обрабатывает файл, а когда он заканчивает, он создает узел в / status (в котором есть все файлы, которые были завершены их процессом).
Мастер следит за узлом / состоянием, и когда что-то было изменено, он получает дочерние элементы и создает поток (чтобы сделать все быстрее, потому что наблюдатели zookeeper и обратные вызовы являются однопоточными), который освобождает эти файлы (удаляет некоторые метаданные из базы данных вернуть ответ клиенту, удалить некоторую переменную и т. д.).
Это один из основных потоков, но у меня есть еще одна важная часть кода, которая прослушивает узлы и обрабатывает их потомков, когда происходят изменения.
Поскольку эта вещь находится в потоке, я создал список узлов, которые уже были закончены, поэтому я не буду выполнять финальный процесс более одного раза, но он был более сложным, и это решение вызвало другие проблемы, некоторые ошибки параллелизма.
Как я и просил
1) В чем проблема с множественным соединением для каждого важного потока, поэтому мне не нужно создавать нити внутри часов и обратного вызова?
2) Есть ли другое решение, которое я могу использовать здесь?