<p>Erreur d'élévation de céleri: [Errno 104] Connexion réinitialisée par l'homologue après le démarrage</p>

Je vois le même problème avec Celery 4.2.0. Je ne l'ai pas avec Celery 4.1.1. Localement, j'obtiens souvent, mais pas toujours, l'Errno 104. Sur une version de travis, il semble échouer plus systématiquement sur 4.2.0 (et réussir sur 4.1.1). Je n'ai pas remarqué la dépendance temporelle signalée par

Pouvez-vous s'il vous plaît fournir la sortie de la commande suivante:

$ celery -A proj report

salut @georgepsarakis ceci est mon rapport

software -> celery:4.2.0 (windowlicker) kombu:4.2.1 py:2.7.5
            billiard:3.5.0.3 py-amqp:2.3.2
platform -> system:Linux arch:64bit, ELF imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:amqp
results:sentinel://:**@10.18.7.1:26379/1;sentinel://:[email protected]:26379/1;sentinel://:[email protected]:26379/1

JSON_AS_ASCII: False
CACHED_OVER_EXEC_MILLISECONDS: 800
LOG_PEEWEE_SQL: False
SESSION_REFRESH_EACH_REQUEST: True
APP_ROOT_PATH: '/data/srv/zns/app'
REDIS_URL: 'redis://:[email protected]:6379/2'
PROJECT_ROOT_PATH: '/data/srv/zns'
FLATPAGES_ROOT: '/data/srv/zns/app/docs'
SESSION_COOKIE_SAMESITE: None
PROPAGATE_EXCEPTIONS: None
CELERYD_SEND_EVENTS: True
REDIS_LOCK_TIMEOUT: 1800
FAKE_HANDLE_TASK: False
SECRET_KEY: u'********'
BROKER_URL: u'amqp://notifer:********@zns.com:5672/notifer_celery_broker'
ENTRY_RATE_LIMIT: 0
SENTRY_DSN: 'http://6a0ce3f93804422da7321f45353c69d7:[email protected]/10'
SWAGGER: {
    'description': '<a href="/docs" target="_blank">\xe5\x85\xb6\xe4\xbb\x96\xe6\x96\x87\xe6\xa1\xa3</a>',
    'doc_expansion': 'list',
    'footer_text': u'\u6709\u4efb\u4f55\u7591\u95ee\u8bf7\u54a8\u8be2 ashinchen',
    'hide_top_bar': True,
    'specs': [{   'endpoint': 'apispec', 'route': '/apispec.json'}],
    'termsOfService': None,
    'title': 'zns API',
    'uiversion': 3,
    'version': '0.0.1'}
LOG_LEVEL: 'info'
APPLICATION_ROOT: '/'
SERVER_NAME: None
LOG_PATH: '/data/srv/zns/logs'
SERVICE_NAME: 'zns'
CELERYD_MAX_TASKS_PER_CHILD: 10000
TESTING: False
MYSQL_URL: 'mysql+pool://user:[email protected]:3306/zns?max_connections=40&stale_timeout=300'
TEMPLATES_AUTO_RELOAD: None
CELERY_RESULT_PERSISTENT: True
JSONIFY_MIMETYPE: 'application/json'
TOF_APP_KEY: u'********'
TOF_SYS_ID: 1
JSON_KEYCASE: u'********'
TOF_URL: 'http://tof.com/api/v1'
FLATPAGES_EXTENSION: ['.md', '.html', '.htm', '.txt']
SESSION_COOKIE_HTTPONLY: True
USE_X_SENDFILE: False
REQUESTS_POOL_SIZE: 10
API_BIND: u'********'
SESSION_COOKIE_SECURE: False
CACHED_EXPIRE_SECONDS: 60
REDIS_SENTINEL: {
    'db': 0,
    'master_name': 'redis-master',
    'nodes': [   ('10.18.7.1', 26379),
                 ('10.16.19.22', 26379),
                 ('10.16.19.21', 26379)],
    'password': u'********'}
SESSION_COOKIE_DOMAIN: None
SESSION_COOKIE_NAME: 'session'
EXCEPTION_RETRY_COUNT: 2
CELERY_TASK_RESULT_EXPIRES: 604800
MAX_COOKIE_SIZE: 4093
ENTRY_RATE_PER: 0
TOF_WEIXIN_SENDER: 'x-ashin'
ENV: 'production'
CELERYD_TASK_SOFT_TIME_LIMIT: 30
DEBUG: False
PREFERRED_URL_SCHEME: 'http'
EXPLAIN_TEMPLATE_LOADING: False
CELERY_RESULT_BACKEND:u'sentinel://:********@10.18.7.1:26379/1;sentinel://:pwd@'10.16.19.22:26379/1;sentinel://:[email protected]:26379/1'
CACHED_CALL: False
FLATPAGES_AUTO_RELOAD: False
MAX_CONTENT_LENGTH: None
REQUEST_ID_KEY: u'********'
NOTIFY_MODULE: 'tof'
JSONIFY_PRETTYPRINT_REGULAR: False
LOG_FUNC_CALL: True
PERMANENT_SESSION_LIFETIME: datetime.timedelta(31)
TOF_EMAIL_SENDER: '[email protected]'
REDIS_CLUSTER: {
    }
TRAP_BAD_REQUEST_ERRORS: None
JSON_SORT_KEYS: u'********'
TRAP_HTTP_EXCEPTIONS: False
SESSION_COOKIE_PATH: None
SEND_FILE_MAX_AGE_DEFAULT: datetime.timedelta(0, 43200)
SPLIT_LOGFILE_BY_LEVEL: False
PRESERVE_CONTEXT_ON_EXCEPTION: None
CELERY_RESULT_BACKEND_TRANSPORT_OPTIONS: {
    'master_name': 'redis-master'}
LOG_IN_FILE: False

comme ce rapport, une dose de mot de passe ne doit pas être remplacée par *

Pour ce que ça vaut, je vois cela aussi avec un projet propre utilisant gevent avec rabbitmq. Après avoir démarré les ouvriers de céleri pendant quelques minutes, nous recevrons une réinitialisation de la connexion et aucune tâche ne sera consommée par la suite.

https://github.com/sihrc/celery-connection-reset

J'ai toujours le même problème jusqu'à présent. (Céleri 4.2) Il a été résolu en rétrogradant la version céleri à 4.1, mais je ne sais pas pourquoi cette erreur s'est produite.

pourriez-vous essayer d'installer le céleri de la branche principale avec toutes ses dépendances du maître et voir ce qui se passe?

Vous obtenez toujours cette erreur avec Celery 4.2.2.

@auvipy Merci, ça marche!

@ yuda110 savez-vous quels changements apportés à vos dépendances ont résolu le problème?

Nous rencontrons ce problème de ConnectionReset et nous utilisons Celery 4.2.1 avec les versions suivantes épinglées qui sont compatibles avec les exigences de céleri:

billiard==3.5.0.4 # Celery needs billiard. There's a bug in 3.5.0.5
kombu==4.2.2-post1 # Celery needs kombu >= 4.2.0, < 5.0
redis==2.10.6

@charlescapps
Oh, j'ai oublié d'effacer cette réponse. Finalement, j'ai dû revenir à la version 4.0.

J'ai rétrogradé à 4.1 et cela a corrigé l'erreur. Je n'ai pas encore essayé la version 4.3.

Cette erreur se produit assez rarement pour nous, et il s'avère que c'est une exception chaînée qui commence par une erreur ConnectionReset du client redis. Je vais simplement activer les tentatives lorsqu'un kombu.exceptions.OperationalError est lancé, car le Celery ChangeLog indique qu'il s'agit d'une erreur pouvant être réessayée.

Je voulais juste dire que le problème persiste dans la version 4.3.0 lors de l'utilisation de RabbitMQ. En quelque sorte, le passage à Redis a résolu le problème.

Nous avons résolu ce problème en effectuant des tentatives avec une interruption exponentielle chaque fois qu'un kombu.exceptions.OperationalError est lancé. Ceux-ci sont censés être réessayés, selon la documentation. Le problème se produit très rarement pour nous, les tentatives sont donc une bonne solution. Nous sommes sur 4.2.1.

Salut,

J'utilise rabbitmq comme courtier et backend et j'ai le même problème.

Quelqu'un a une solution?

Merci d'avance.

Même problème ici. C'est 100% reproductible pour moi. Pour une raison quelconque, la socket du courtier s'éteint après ce qui semble être l'intervalle de pulsation.

rapport:

software -> celery:4.3.0 (rhubarb) kombu:4.5.0 py:3.6.7
            billiard:3.6.0.0 py-amqp:2.4.2
platform -> system:Linux arch:64bit, ELF
            kernel version:4.18.0-20-generic imp:CPython
loader   -> celery.loaders.app.AppLoader
settings -> transport:amqp results:rpc:///

broker_url: 'amqp://guest:********<strong i="7">@localhost</strong>:5672//'
result_backend: 'rpc:///'
result_persistent: False
task_default_queue: 'something something'
result_expires: 3600
task_ignore_result: False
task_serializer: 'json'
result_serializer: 'json'
accept_content: ['json']
timezone: 'Europe/Berlin'
enable_utc: True

Je dois dire que mes problèmes ont commencé lorsque je suis passé à Erlang 22.0. Mais cela peut aussi être incidentiel.

pouvez-vous suggérer une solution? Si vous le pouvez, cela sera inclus dans 4.4.0rc2

Je peux également confirmer ce comportement sur 4.3.0 avec gevent worker. Le passage de gevent à prefork semble le résoudre. J'ai essayé de passer à la version 4.1.1 mais cela ne semble pas fonctionner sur Python 3.7 car il nécessite une ancienne version de gevent (1.2.2) qui ne se compilera même pas sur Python 3.7. J'ai remarqué que lorsque le problème commence, les journaux rabbitmq affichent ce message:

missed heartbeats from client, timeout: 60s

Fait intéressant, malgré l'échec du rythme cardiaque, le travailleur reprend les tâches et les traite correctement. C'est juste que les commandes celery inspect expirent jusqu'au redémarrage du worker. flower affiche toujours des informations sur le tableau de bord pour le travailleur, mais le fait de cliquer sur le travailleur lui-même obtient une erreur 404 Not Found et les échecs des journaux de fleurs liés aux commandes d'inspection du céleri:

monitor_1    | 2019-08-27 17:39:05.483286 [warning  ] 404 GET /worker/celery<strong i="11">@38245f8fef62</strong> (172.20.0.1): Unknown worker 'celery<strong i="12">@38245f8fef62</strong>' [tornado.general] 
monitor_1    | 2019-08-27 17:39:24.608962 [warning  ] 'stats' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.609429 [warning  ] 'active_queues' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.609847 [warning  ] 'registered' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.610221 [warning  ] 'scheduled' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.610905 [warning  ] 'active' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.611369 [warning  ] 'reserved' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.611890 [warning  ] 'revoked' inspect method failed [flower.api.control] 
monitor_1    | 2019-08-27 17:39:24.612512 [warning  ] 'conf' inspect method failed [flower.api.control] 

besoin de quelqu'un pour vérifier cela sur céleri 4.4.0rc3 + kombu 4.6.3?

Ça ira. Pour info, le céleri 4.4.0rc3 nécessite kombu 4.6.4:

celery 4.4.0rc3 has requirement kombu<5.0,>=4.6.4, but you'll have kombu 4.6.3 which is incompatible.

Ok, 4.4.0rc3 semble résoudre ce problème. Je l'ai laissé pendant plus de 5 minutes sans erreur de pulsation en utilisant le worker gevent.

kombu 4.6.3 est également compatible

Si tel est le cas, vous voudrez peut-être mettre à jour le fichier des exigences sur le projet céleri.

Mais qu'avons-nous changé?

J'adorerais aussi avoir un aperçu de ce qui a été changé et qui a provoqué sa fermeture, ou un lien vers un PR / code / etc. Nous sommes affectés, et l'atténuation (prefork, rabbitmq, céleri 4.3) en désactivant les battements cardiaques, ce qui est sous-optimal.

@auvipy Ping?

Ok, 4.4.0rc3 semble résoudre ce problème. Je l'ai laissé pendant plus de 5 minutes sans erreur de pulsation en utilisant le worker gevent.

le problème a été résolu sur la base de ces commentaires

@auvipy Il semble que plusieurs problèmes entraînent des erreurs similaires. Ce serait formidable si vous essayiez de reproduire le bogue localement, éventuellement avec certaines anciennes versions de Celery, avant de résoudre le problème.

il vous est suggéré d'essayer la branche principale.

Je suggère de reproduire le bogue avec l'une des versions antérieures (par exemple 4.1, 4.2, 4.3) et de m'assurer que la mise à jour vers 4.4 seule résolvait le problème. Clore le bogue sans votre propre vérification - basée sur les commentaires d'une seule personne - semble un peu hâtive.

puisque vous êtes confronté au problème, vous devriez être le premier à vérifier comme vous l'avez suggéré. @czyzby

vous devriez être le premier à vérifier comme vous l'avez suggéré

_ "Devrait"? _;) S'il y a quelqu'un qui _devrait_ se soucier de la qualité du projet, ce sont les responsables officiels. Je suis reconnaissant que vous offriez votre logiciel gratuitement, mais vous ne pouvez pas raisonnablement vous attendre à ce que tous vos utilisateurs contribuent au projet.

Quoi qu'il en soit, je n'ai plus la configuration qui a causé le problème, mais je pense que le problème a persisté même en cas de files d'attente vides sans tâches définies, donc il pourrait être facile à reproduire. J'ai depuis résolu le problème avec une solution de contournement en migrant vers Redis, car notre équipe pouvait facilement changer les technologies à l'époque. Et, pour être tout à fait honnête, nous envisageons de passer à RQ en raison d'autres problèmes avec Celery.

4.4.0rc4 semble également résoudre ce problème,

toute autre personne qui peut le vérifier, il est corrigé par céleri == 4.4.0rc4

@auvipy J'étais sur 4.3.0 avec occasionnellement Connection reset . Plus de problèmes avec 4.4.0rc4 pour moi.

toute autre personne qui peut le vérifier, il est corrigé par céleri == 4.4.0rc4

Il a eu le problème sur 4.3.0 assez souvent - avec 4.4.0rc4 le problème se produit beaucoup moins souvent - mais se produit encore de temps en temps.
J'utilise redis-server 5.0.6 et python redis Client 3.3.11 avec ~ 14 tâches périodiques (toutes les 30 secondes).
Je vous demanderais donc de rouvrir le dossier.
Merci!

Il a eu le problème sur 4.3.0 assez souvent - avec 4.4.0rc4 le problème se produit beaucoup moins souvent - mais se produit encore de temps en temps.
J'utilise redis-server 5.0.6 et python redis Client 3.3.11 avec ~ 14 tâches périodiques (toutes les 30 secondes).
Je vous demanderais donc de rouvrir le dossier.
Merci

En effet, le problème se produit toujours avec les paramètres par défaut. Cependant, comme mentionné dans d'autres threads, définir broker_heartbeat = 0 dans celeryconfig.py semble aider.

Même après la mise à niveau vers le céleri 4.4.0rc4 et l'ajout de CELERY_BROKER_HEARTBEAT = 0 dans celery.py, rien ne semble changer pour moi, mais l'erreur persiste.

le problème n'était toujours pas résolu après la rétrogradation de céleri 4.2.0 à 4.10

Les versions suivantes sont utilisées dans notre projet:
billard == 3.5.0.2, kombu == 4.1.0, céleri == 4.1.0, amqp == 2.4.2

veuillez suggérer

Nous avons commencé à voir cela, ou quelque chose qui ressemble beaucoup à ce problème.

logiciel -> céleri: 4.3.0 (rhubarbe) kombu: 4.5.0 py: 2.7.12
billard: 3.6.0.0 redis: 3.2.1

Cela a commencé à se produire plusieurs fois par jour, sans réel changement.
Pour notre prochaine version, nous essaierons de mettre à niveau vers les versions les plus récentes, céleri 4.4.0, redis, etc. et faire un rapport.

Cela se passe pour moi avec (concurrency = 1000 (gevent) & redis en tant que courtier):
céleri == 4.4.0 (falaises)
kombu == 4.6.7
billard == 3.6.2.0
(py-) redis == 3.4.1

Version du serveur Redis = 5.0.7
Python 3.7.3

https://sentry.io/share/issue/85f87e60a7c441198c082b9ebf051693/

• 7 tâches sont définies pour s'exécuter toutes les 10 secondes.
• L'erreur ne se produit que dans le battement de céleri, et très rarement une erreur se produit dans moins de 3 cas toutes les heures.

Mots clés

• enregistreur: celery.beat
• exécution: CPython 3.7.5

Environnement

• Linux-4.15.0-1060-aws-x86_64-avec-Ubuntu-18.04-bionic
• Python 3.7.5 (par défaut, 7 novembre 2019, 10:50:52) [GCC 8.3.0]
• Serveur Redis v = 4.0.9 sha = 00000000: 0 malloc = jemalloc-3.6.0 bits = 64 build = 9435c3c2879311f3
• céleri == 4.4.0
• billard == 3.6.1.0
• kombu == 4.6.7
• redis == 3.3.11

Cela m'arrive lorsque je me connecte à un serveur TCP en utilisant open_connection d'Asyncio. 15 minutes après que je me connecte au serveur distant dans notre VPN, il me déconnecte. Je soupçonne que c'est parce que la connexion est inactive. La même chose ne se produit pas lorsque je me connecte à partir du serveur distant. Cela semble être lié au réseau.

J'ai résolu mon cas! Uff.

Ce n'était pas un problème de céleri. J'en ai essayé quelques versions, dont 4. [234] .0, et j'ai essayé quelques versions d'interfaces python pour redis. Et j'ai toujours eu, plus moins, le même taux d'échec (environ 2 ‰ pour 0,5 million de requêtes)

La solution consistait à reconfigurer le serveur Redis, c'est-à-dire à désactiver la limite de tampon de sortie client pour toutes les classes. Selon la documentation de Redis :

Un client est immédiatement déconnecté une fois que la limite stricte est atteinte, ou si la limite souple est atteinte et reste atteinte pendant le nombre de secondes spécifié (en continu).
…
La limite dure ou la limite souple peuvent être désactivées en les mettant à zéro.

J'espère que cela vous aidera tous aussi. Ou peut-être que vous améliorerez ma solution.

J'ai résolu mon cas! Uff.

Ce n'était pas un problème de céleri. J'en ai essayé quelques versions, dont 4. [234] .0, et j'ai essayé quelques versions d'interfaces python pour redis. Et j'ai toujours eu, plus moins, le même taux d'échec (environ 2 ‰ pour 0,5 million de requêtes)

La solution consistait à reconfigurer le serveur Redis, c'est-à-dire à désactiver la limite de tampon de sortie client pour toutes les classes. Selon la documentation de Redis :

Un client est immédiatement déconnecté une fois que la limite stricte est atteinte, ou si la limite souple est atteinte et reste atteinte pendant le nombre de secondes spécifié (en continu).
…
La limite dure ou la limite souple peuvent être désactivées en les mettant à zéro.

J'espère que cela vous aidera tous aussi. Ou peut-être que vous améliorerez ma solution.

Cela a également fonctionné pour moi, là où aucune des autres suggestions n'a fonctionné. Merci!

Je peux également confirmer que cela a résolu le problème de ma configuration! Merci d'avoir mis du temps dans ce @rganowski!

Génial si cela résout le problème, mais avant de commencer à supprimer les valeurs par défaut du fichier de configuration, je pense que ce serait formidable de savoir ce que fait ce paramètre, et pourquoi il fait partie de la configuration par défaut?

@Moulde Je ne suis pas tout à fait sûr de ce que vous entendez par la suppression des valeurs par défaut du fichier de configuration. Quel fichier de configuration? Voulez-vous dire modifier les paramètres du serveur Redis par défaut que j'ai indiqués?

Je voudrais également savoir pourquoi de tels défauts existent? Était-ce conscient? Dans l'affirmative, quel est le risque d'y renoncer? Mais, pour être honnête, je ne vais pas vérifier cela. J'avais une tâche 10MD, je devais ajouter 3MD gratuitement.

Personne n'a dit que cela résout le problème. J'ai dit que j'avais trouvé une solution pour mon cas. Deux autres potes ont dit que cela fonctionnait aussi pour eux. J'ai lu cela avec plaisir. Mais je lis vos paroles de telle manière: "prouvez-le". Ai-je tort?

S'il vous plaît, testez-le sur votre application et faites-nous savoir si cela fonctionne pour vous. Si vous résolvez d'autres doutes, n'oubliez pas de les partager avec les autres.

@rganowski On dirait que nous sommes d'accord, et oui, je vois ce que tu veux dire avec mon libellé, ce n'était pas voulu comme ça, mais plus pour ajouter un peu de scepticisme sain avant de modifier les valeurs par défaut du système, et peut-être un peu critique de la documentation - car une petite information sur la raison pour laquelle ce paramètre est nécessaire serait géniale, à côté de la partie "ce qu'il fait" qui se trouve dans le fichier :)
Et merci pour le temps que vous y consacrez, je ne l'aurais pas compris par moi-même.

Le problème est clos, car il n'y avait pas d'erreur dans le code Celery, mais le problème derrière le problème n'est pas résolu. Je pense qu'un avertissement adéquat dans la documentation des paramètres du backend redis devrait être ajouté.

En cherchant sur Google «client-output-buffer-limit», nous pouvons trouver de nombreux articles intéressants. L'un, maintenant déjà 6 ans, a - en résultats - un très beau titre The Replication Buffer - Comment éviter les maux de tête Devops . Là on peut lire:

Avant d'augmenter la taille des tampons de réplication, vous devez vous assurer que vous disposez de suffisamment de mémoire sur votre machine.

Dans un autre article Client Buffers-Avant de prendre Redis en production, vérifiez ceci! l'auteur dit:

Par défaut, les clients normaux (commandes d'exécution normales) ne sont pas limités car ils ne reçoivent pas de données sans demander (de manière push), mais juste après une demande, donc seuls les clients asynchrones peuvent créer un scénario où les données sont demandées plus rapidement qu'elles ne le peuvent lis.

N'est-ce pas notre cas?

Pour moi, du moins jusqu'à présent, la reconfiguration s'est avérée être le salut. Pas de nouvelles erreurs '104', sur une charge vraiment lourde et instantanée.

@rganowski @Moulde @ CM2Walki

Salut, je peux sembler très naïf mais pouvez-vous s'il vous plaît me dire où je peux faire les modifications nécessaires afin de désactiver la limite de tampon de sortie client pour toutes les classes. Comme je reçois également la même erreur, mais je ne suis pas en mesure d'interpréter votre réponse. Alors, pouvez-vous expliquer votre réponse afin que je puisse apporter les modifications nécessaires. Merci!

Le problème est clos, car il n'y avait pas d'erreur dans le code Celery, mais le problème derrière le problème n'est pas résolu. Je pense qu'un avertissement adéquat dans la documentation des paramètres du backend redis devrait être ajouté.

En cherchant sur Google «client-output-buffer-limit», nous pouvons trouver de nombreux articles intéressants. L'un, maintenant déjà 6 ans, a - en résultats - un très beau titre The Replication Buffer - Comment éviter les maux de tête Devops . Là on peut lire:

Avant d'augmenter la taille des tampons de réplication, vous devez vous assurer que vous disposez de suffisamment de mémoire sur votre machine.

Dans un autre article Client Buffers-Avant de prendre Redis en production, vérifiez ceci! l'auteur dit:

Par défaut, les clients normaux (commandes d'exécution normales) ne sont pas limités car ils ne reçoivent pas de données sans demander (de manière push), mais juste après une demande, donc seuls les clients asynchrones peuvent créer un scénario où les données sont demandées plus rapidement qu'elles ne le peuvent lis.

N'est-ce pas notre cas?

Pour moi, du moins jusqu'à présent, la reconfiguration s'est avérée être le salut. Pas de nouvelles erreurs '104', sur une charge vraiment lourde et instantanée.

apprécie vraiment une amélioration de doc PR

@girijesh97 @auvipy

In redis.conf

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 0 0 0
client-output-buffer-limit pubsub 0 0 0

@rganowski Sir Encore une fois, je peux paraître très naïf mais j'ai une application Django dans laquelle j'utilise du céleri (version 4.4.2) et je suis confronté au problème d'erreur de connexion. Pouvez-vous s'il vous plaît aider à localiser ou créer ce fichier redis.conf. Dois-je créer ce fichier dans mon application ou il est disponible dans un package?

Si votre cas est le même, dont nous parlions, votre céleri utilise le backend des résultats du serveur Redis. Le fichier que j'ai mentionné est le fichier de configuration du serveur redis standard. C'est pourquoi ce n'est en fait pas un problème de céleri mais un effet secondaire.

@auvipy Existe-t-il un correctif pour RabbitMQ en tant que courtier et moteur de résultat pour le même problème. Voir cela dans 4.4 également sur les tâches de longue durée. Le correctif ci-dessus concerne uniquement le backend Redis.

Voir également ce problème se produire par intermittence avec RabbitMQ et céleri 4.2.0. Même s'il est intégré dans la gestion des tentatives plutôt que de le forcer aux utilisateurs du package.

Je le vis également. Je suis sur Celery 4.3.0 et RabbitMQ 3.3.5.