Есть две возможные причины отклонения "аппаратного обеспечения" .bind() -s
Один уже был в вашем сообщении - при условии, что JeroMQ-сервисы действительно пытаются жестко .bind() в местах, где вы хотели бы вместо .connect(). Просмотрите основание кода, чтобы подтвердить это (с помощью возможного форка / мода, обходящего любой такой дискомфорт с измененным способом обслуживания), или отклоните эту альтернативу, если виноват не код.
Но позвольте мне упомянуть еще одну возможную причину , которая довольно часто была проблемой при PoC / прототипировании.
Инструменты макетов на ранних стадиях подвержены сбоям (и да, иногда они мирно терпят крах, но иногда случаются сбои чаще или сложнее, чем команда PoC готова жить).
Если кодовая база (пока) не разработана должным образом на этом этапе, чтобы четко обрабатывать также управление ресурсами (правильное использование явного aSocket.setsockopt( LINGER, 0 ) (смертельная необходимость в нативных версиях API до 4.x) {aSocket|aMessage}.close() и Context.term() методов), который выполняет чистый выход даже после сбоя, существуют ситуации, когда ваш код оставил все еще активный (не демонтированный) один или несколько Context() -инстанций, которые (все еще ) заблокировать аппаратные ресурсы, так как пока не было разрешено их освобождать.
Это иногда приводило к необходимости перезагрузки платформы, так как в инсталлированном Context() экземпляре нет другого способа получить «чистку пылесосом» (позор тем, кто не сливает и не защищает код для выживания до заключительный этап в триаде try: except: finally: для принудительного завершения и чистого освобождения всех выделенных ресурсов).