У меня есть много скриптов, которые используют следующий подход для повторного подключения:
while True:
try:
mqExch.channel.connection.drain_events(timeout=25)
except socket.timeout:
hb.beat() # let our supervisor know we are not hung
Это не пика, а комбу, но принципы можно применять. Метод drain_events является ядром потребления сообщений, то есть он зацикливается на получение сообщений и выполнение обратного вызова для обработки сообщения. Как вы можете видеть здесь, у меня есть библиотека сокетов низкого уровня, тайм-аут которой каждые 25 секунд. В некоторых библиотеках мне пришлось пропатчить пару строк кода, чтобы это поведение работало без сбоев внутри модуля.
В любом случае, пульс, отправляемый hb.beat, отслеживается процессом супервизора, и этот процесс убивает скрипт, если в слишком короткий промежуток времени слишком много сбоев. После убийства сценария супервизор перезапускает его. Это хорошо сработало в случае периодических сетевых ошибок или перезапусков брокера MQ. Хотя я мог бы заставить свой сценарий выполнить переподключение, было проще убить и перезапустить.