Je cours Celery 2.2.4/djCelery 2.2.4, en utilisant RabbitMQ 2.1.1 comme un backend. J'ai récemment mis en ligne deux nouveaux serveurs de céleri - j'avais utilisé 2 travailleurs sur deux machines avec un total de ~ 18 threads et sur mes nouvelles boîtes gonflées (36g RAM + dual quad-core hyper-threaded), je cours 10 les travailleurs avec 8 threads chacun, pour un total de 180 threads - mes tâches sont toutes assez petites donc ça devrait aller.céleri .delay se bloque (récent, pas un problème d'authentification)
Les noeuds fonctionnent correctement depuis quelques jours, mais aujourd'hui j'ai remarqué que .delaay() est suspendu. Quand je l'interrompre, je vois un retraçage qui pointe ici:
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)
J'ai vérifié les journaux de lapin, et je vois le processus tente de se connecter comme:
=INFO REPORT==== 12-Jun-2011::22:58:12 ===
accepted TCP connection on 0.0.0.0:5672 from x.x.x.x:48569
J'ai mon Céleri log niveau fixé à INFO, mais je ne vois rien de particulièrement intéressant dans les journaux de Céleri SAUF que 2 des travailleurs ne peuvent pas se connecter au courtier:
[2011-06-12 22:41:08,033: ERROR/MainProcess] Consumer: Connection to broker lost. Trying to re-establish connection...
Tous les autres nœuds ar e capable de se connecter sans problème.
Je sais qu'il y avait une publication (RabbitMQ/Celery with Django hangs on delay/ready/etc - No useful log info) l'année dernière de nature similaire, mais je suis assez certain que c'est différent. Se pourrait-il que le nombre de travailleurs crée une sorte de condition de course dans amqplib - J'ai trouvé this thread qui semble indiquer que amqplib n'est pas thread-safe, pas sûr si cela compte pour Céleri.
EDIT: J'ai essayé celeryctl purge sur les deux nœuds - sur un il réussit, mais l'autre, elle échoue avec l'erreur AMQP suivante:
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')
Sur les deux nœuds, avec le inspect stats se bloque "Impossible de fermer la connexion" traceback ci-dessus. Je suis à perte ici.
EDIT2. j'ai pu supprimer l'échange incriminé à l'aide exchange.delete de camqadm et maintenant le deuxième noeud se bloque trop :(
EDIT3: Une chose qui a changé récemment que j'ai ajouté un montant supplémentaire vhost rabbitmq, que mon nœud de mise en scène se connecte à