celery .delay зависает (недавно, не проблема авторизации)

Я использую Celery 2.2.4 / djCelery 2.2.4, используя RabbitMQ 2.1.1 как бэкэнд. Я недавно подключил к сети два новых сервера сельдерея - у меня было 2 рабочих на двух машинах с общим количеством потоков ~ 18, а на моих новых усиленных ящиках (36g RAM + двухъядерный четырехъядерный процессор) я использую 10 рабочих с 8 потоками каждый, всего 180 потоков - все мои задачи довольно маленькие, так что все должно быть нормально.

Узлы работали нормально последние несколько дней, но сегодня я заметил это . delaay () зависает. Когда я прерываю его, я вижу трассировку, которая указывает здесь:

File "/home/django/deployed/releases/20110608183345/virtual-env/lib/python2.5/site-packages/celery/task/base.py", line 324, in delay
    return self.apply_async(args, kwargs)
File "/home/django/deployed/releases/20110608183345/virtual-env/lib/python2.5/site-packages/celery/task/base.py", line 449, in apply_async
    publish.close()
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/kombu/compat.py", line 108, in close
    self.backend.close()
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/channel.py", line 194, in close
    (20, 41),    # Channel.close_ok
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/abstract_channel.py", line 89, in wait
    self.channel_id, allowed_methods)
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/connection.py", line 198, in _wait_method
    self.method_reader.read_method()
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/method_framing.py", line 212, in read_method
    self._next_method()
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/method_framing.py", line 127, in _next_method
    frame_type, channel, payload = self.source.read_frame()
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/transport.py", line 109, in read_frame
    frame_type, channel, size = unpack('>BHI', self._read(7))
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/transport.py", line 200, in _read
    s = self.sock.recv(65536)

Я проверил журналы Rabbit и вижу, что процесс пытается подключиться следующим образом:

=INFO REPORT==== 12-Jun-2011::22:58:12 ===
accepted TCP connection on 0.0.0.0:5672 from x.x.x.x:48569

У меня уровень журнала Celery установлен на INFO , но я не вижу ничего особенно интересного в журналах Celery, ЗА ИСКЛЮЧЕНИЕМ того, что 2 рабочих не могут подключиться к брокеру:

[2011-06-12 22:41:08,033: ERROR/MainProcess] Consumer: Connection to broker lost. Trying to re-establish connection...

Все остальные узлы могут подключиться без проблем.

I знаю, что в прошлом году была аналогичная публикация ( RabbitMQ / Celery с Django зависает при задержке / готовности / и т. д. - Нет полезной информации журнала ), но я почти уверен, что это другое. Может быть, огромное количество рабочих создает своего рода состояние гонки в amqplib -Я нашел этот поток, который, кажется, указывает на то, что amqplib не является потокобезопасным, не уверен, имеет ли это значение для Celery.

РЕДАКТИРОВАТЬ: Я пробовал ] celeryctl purge на обоих узлах - на одном она завершается успешно, но на другом не удается из-за следующей ошибки AMQP:

AMQPConnectionException(reply_code, reply_text, (class_id, method_id))
    amqplib.client_0_8.exceptions.AMQPConnectionException: 
    (530, u"NOT_ALLOWED - cannot redeclare exchange 'XXXXX' in vhost 'XXXXX' 
     with different type, durable or autodelete   value", (40, 10), 'Channel.exchange_declare')

На обоих узлах проверить статистику зависает с надписью «невозможно закрыть соединение "трассировка выше. Я здесь в растерянности.

РЕДАКТИРОВАТЬ2: Мне удалось удалить ошибочный обмен с помощью exchange.delete из camqadm , и теперь второй узел тоже зависает: (.

EDIT3: Одна вещь, которая также недавно изменилась, - это то, что я добавил дополнительный виртуальный хост в rabbitmq, к которому подключается мой промежуточный узел.