Должен ли я добавить спит к инициализации программы zeroMQ, чтобы избежать ошибок по умолчанию? - PullRequest
Новая
       2

Должен ли я добавить спит к инициализации программы zeroMQ, чтобы избежать ошибок по умолчанию?

4 голосов
/ 07 февраля 2012

Я работаю над проверкой концепции zeroMQ, которая включает главный процесс, который публикует управляющие команды, а также извлекает и извлекает данные из любого числа рабочих процессов.

Похоже, что при инициализации мастер и рабочие (отдельные процессы) иногда не синхронизируются, если я запускаю их с помощью сценария оболочки. Тем не менее, я никогда не видел этого, если я запускаю их в любом порядке вручную (в отдельных окнах консоли). Я начинаю рассматривать добавление sleep () после того, как каждый процесс связывается / соединяется с сокетами, чтобы избежать этого очевидного heisenbug - но мне также интересно, просто ли я глупый. Любой совет?

Вот как выглядит сценарий оболочки, который иногда дает сбой. Мастер разговаривает с рабочими, используя как PUB, так и PUSH, а также возвращает информацию, используя гнездо PULL. Я думаю, что heisenbug вызывается, когда PUB-сообщение от мастера иногда не замечается одним из рабочих. 

echo "starting worker A in background"
python pWorkerA.py > /tmp/A.out &
echo "starting worker B in background"
python pWorkerB.py > /tmp/B.out &
echo "starting master"
python abMaster.py

Я чувствую, что изменяю, если использую сон ()

1 Ответ

1 голос
/ 08 февраля 2012

Вы должны предположить, что сообщения, отправленные на PUB, не будут поступать на SUB-сокеты, пока они не установят свои соединения. Установление соединений занимает некоторое, хотя и очень небольшое количество времени, поэтому любые сообщения, отправленные в этом маленьком окне, не будут поступать на SUB, которые еще не подключились. Как вы уже предложили, простой способ избежать этого - добавить спящий режим в мастер после привязки. Это не совсем надежно, так как технически работники могут быть очень медленными для подключения или запускаться после мастера, и в случае успеха фактический сигнал отсутствует.

Более надежный подход, если вам нужно подтвердить, что работники подключены, - это иметь механизм рукопожатия, чтобы работники отправляли небольшое сообщение «Привет, я готов» (на другом канале) мастеру. после подключения. Затем мастер начинает публиковать сообщения только после получения необходимого количества рукопожатий (в зависимости от логики, подходящей для вашего приложения).

...