Celery: RunTimeError : Acquérir sur un pool fermé, essayez d'utiliser l'inspection de contrôle

Liste de contrôle

• [x] J'ai inclus la sortie de celery -A proj report dans le numéro.
  (si vous n'êtes pas en mesure de le faire, spécifiez au moins le céleri
  version affectée).

logiciel -> céleri:4.0.2 (latentcall) kombu:4.1.0 py:2.7.13 ou (py:2.7.12)
billard:3.5.0.3 redis:2.10.5
plate-forme -> système:Darwin arch:64bit imp:CPython . (bien qu'habituellement : system:Linux arch:64bit, ELF)
chargeur -> céleri.loaders.app.AppLoader
paramètres -> transport:redis résultats:redis :// localhost:6380/

BROKER_TRANSPORT_OPTIONS : {
'fanout_patterns' : vrai, 'fanout_prefix' : vrai}
CELERY_TASK_COMPRESSION : 'gzip'
CELERY_TIMEZONE : "UTC"
CELERY_RESULT_SERIALIZER : 'json'
CELERY_BROKER_URL : u' redis://localhost : 6380//'
CELERY_TASK_SERIALIZER : 'json'
CELERY_RESULT_EXPIRES : 60
CELERY_ACCEPT_CONTENT : ['application/json']
TIME_ZONE : "UTC"
CELERY_MESSAGE_COMPRESSION : 'gzip'
CELERY_TASK_ALWAYS_EAGER : Faux
CELERY_RESULT_BACKEND : u' redis://localhost : 6380/'

• [x] J'ai vérifié que le problème existe avec la branche master de Celery.

Se produit également sur le céleri 4.1.0.

Étapes à reproduire

Essayez d'utiliser le module control . Dans mon cas, je reçois le active_queues() .

Comportement prévisible

Je pense que tant que le système est en bon état, je devrais pouvoir obtenir les informations à partir du module control . Je ne comprends pas exactement pourquoi parfois la piscine est fermée et d'autres fois non.

Comportement réel

C'est peut-être le même problème que dans #1839

Le code aura une erreur d'exécution, je ne peux donc pas rechercher les données dont j'ai besoin à partir du céleri.

File "/.../tasks.py", line 80, in workers_on_queue
    for k, v in six.viewitems(celery_app.control.inspect().active_queues()):
  File "/.../lib/python2.7/site-packages/celery/app/control.py", line 116, in active_queues
    return self._request('active_queues')
  File "/.../lib/python2.7/site-packages/celery/app/control.py", line 81, in _request
    timeout=self.timeout, reply=True,
  File "/.../lib/python2.7/site-packages/celery/app/control.py", line 436, in broadcast
    limit, callback, channel=channel,
  File "/.../lib/python2.7/site-packages/kombu/pidbox.py", line 315, in _broadcast
    serializer=serializer)
  File "/.../lib/python2.7/site-packages/kombu/pidbox.py", line 285, in _publish
    with self.producer_or_acquire(producer, chan) as producer:
  File "/usr/local/Cellar/python/2.7.13_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/contextlib.py", line 17, in __enter__
    return self.gen.next()
  File "/.../lib/python2.7/site-packages/kombu/pidbox.py", line 247, in producer_or_acquire
    with self.producer_pool.acquire() as producer:
  File "/.../lib/python2.7/site-packages/kombu/resource.py", line 74, in acquire
    raise RuntimeError('Acquire on closed pool')

Cela ne se produit que lorsque nous utilisons le module control . Parfois ça marche bien.

Ce chemin de code était même dans une boucle de nouvelle tentative, donc à la fin, il n'a toujours pas réussi à s'exécuter.