Celery: Celery Worker stürzt nach der ersten Aufgabe mit TypeError ab: „NoneType“-Objekt ist nicht aufrufbar

Der Fehler wiederholt sich im Protokoll, da der Celery-Worker-Daemon abstürzt, sodass Systemd ihn neu startet.

@ask , self._quick_put ist irgendwie nicht definiert. Soll Billard vor dem Aufrufen nach einem None suchen, die Ausnahme abfangen oder sollte self._quick_put niemals None sein?

Wenn ich billiard/pool.py#L1483 in if self.threads or self._quick_put is None: ändere, stürzt Celery nicht mehr ab, aber aus irgendeinem Grund verarbeiten die Arbeiter nie irgendwelche Aufgaben.

Ausführlichere Ausgabe mit Logging-Level DEBUG:

[2016-11-27 14:48:09,875: DEBUG/MainProcess] | Worker: Preparing bootsteps.
[2016-11-27 14:48:09,877: DEBUG/MainProcess] | Worker: Building graph...
[2016-11-27 14:48:09,878: DEBUG/MainProcess] | Worker: New boot order: {Timer, Hub, Pool, Autoscaler, StateDB, Beat, Consumer}
[2016-11-27 14:48:09,889: DEBUG/MainProcess] | Consumer: Preparing bootsteps.
[2016-11-27 14:48:09,889: DEBUG/MainProcess] | Consumer: Building graph...
[2016-11-27 14:48:09,898: DEBUG/MainProcess] | Consumer: New boot order: {Connection, Agent, Events, Mingle, Tasks, Control, Gossip, Heart, event loop}
[2016-11-27 14:48:09,908: DEBUG/MainProcess] | Worker: Starting Hub
[2016-11-27 14:48:09,908: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:09,908: DEBUG/MainProcess] | Worker: Starting Pool
[2016-11-27 14:48:09,998: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:09,999: DEBUG/MainProcess] | Worker: Starting Consumer
[2016-11-27 14:48:10,000: DEBUG/MainProcess] | Consumer: Starting Connection
[2016-11-27 14:48:10,016: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'cluster_name': 'rabbit<strong i="6">@rabbitmq</strong>', 'product': 'RabbitMQ', 'version': '3.5.6', 'information': 'Licensed under the MPL.
  See http://www.rabbitmq.com/', 'capabilities': {'authentication_failure_close': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'per_consumer_qos': True, 'basic.nack': True, 'publisher_confirms': True, 'connection.blocked': True, 'exchange_exchange_bindings': True}, 'copyright': 'Copyright (C) 2007-2015 Pivotal Software, Inc.', 'platform': 'Erlang/OTP'}, mechanisms: ['AMQPLAIN', 'PLAIN'], locales: ['en_US']
[2016-11-27 14:48:10,018: INFO/MainProcess] Connected to amqp://user:**@10.136.131.6:5672//
[2016-11-27 14:48:10,018: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:10,019: DEBUG/MainProcess] | Consumer: Starting Events
[2016-11-27 14:48:10,031: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'cluster_name': 'rabbit<strong i="7">@rabbitmq</strong>', 'product': 'RabbitMQ', 'version': '3.5.6', 'information': 'Licensed under the MPL.  See http://www.rabbitmq.com/', 'capabilities': {'authentication_failure_close': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'per_consumer_qos': True, 'basic.nack': True, 'publisher_confirms': True, 'connection.blocked': True, 'exchange_exchange_bindings': True}, 'copyright': 'Copyright (C) 2007-2015 Pivotal Software, Inc.', 'platform': 'Erlang/OTP'}, mechanisms: ['AMQPLAIN', 'PLAIN'], locales: ['en_US']
[2016-11-27 14:48:10,034: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:10,034: DEBUG/MainProcess] | Consumer: Starting Mingle
[2016-11-27 14:48:10,035: INFO/MainProcess] mingle: searching for neighbors
[2016-11-27 14:48:10,036: DEBUG/MainProcess] using channel_id: 1
[2016-11-27 14:48:10,041: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:10,061: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'cluster_name': 'rabbit<strong i="8">@rabbitmq</strong>', 'product': 'RabbitMQ', 'version': '3.5.6', 'information': 'Licensed under the MPL.  See http://www.rabbitmq.com/', 'capabilities': {'authentication_failure_close': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'per_consumer_qos': True, 'basic.nack': True, 'publisher_confirms': True, 'connection.blocked': True, 'exchange_exchange_bindings': True}, 'copyright': 'Copyright (C) 2007-2015 Pivotal Software, Inc.', 'platform': 'Erlang/OTP'}, mechanisms: ['AMQPLAIN', 'PLAIN'], locales: ['en_US']
[2016-11-27 14:48:10,063: DEBUG/MainProcess] using channel_id: 1
[2016-11-27 14:48:10,064: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,189: INFO/MainProcess] mingle: sync with 3 nodes
[2016-11-27 14:48:11,190: DEBUG/MainProcess] mingle: processing reply from celery<strong i="9">@worker03</strong>
[2016-11-27 14:48:11,190: DEBUG/MainProcess] mingle: processing reply from celery<strong i="10">@worker02</strong>
[2016-11-27 14:48:11,190: DEBUG/MainProcess] mingle: processing reply from celery<strong i="11">@worker01</strong>
[2016-11-27 14:48:11,190: INFO/MainProcess] mingle: sync complete
[2016-11-27 14:48:11,191: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,191: DEBUG/MainProcess] | Consumer: Starting Tasks
[2016-11-27 14:48:11,244: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,244: DEBUG/MainProcess] | Consumer: Starting Control
[2016-11-27 14:48:11,244: DEBUG/MainProcess] using channel_id: 2
[2016-11-27 14:48:11,246: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,251: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,251: DEBUG/MainProcess] | Consumer: Starting Gossip
[2016-11-27 14:48:11,252: DEBUG/MainProcess] using channel_id: 3
[2016-11-27 14:48:11,253: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,257: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,258: DEBUG/MainProcess] | Consumer: Starting Heart
[2016-11-27 14:48:11,259: DEBUG/MainProcess] using channel_id: 1
[2016-11-27 14:48:11,260: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,261: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,261: DEBUG/MainProcess] | Consumer: Starting event loop
[2016-11-27 14:48:11,264: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[0eba267c-72e4-40ea-91dd-a1a7ab17c514]
[2016-11-27 14:48:11,265: DEBUG/MainProcess] TaskPool: Apply <function _fast_trace_task at 0x7ff469300950> (args:('wakatime.tasks.cache_coding_activity', '0eba267c-72e4-40ea-91dd-a1a7ab17c514', {'argsrepr': '()', 'task': 'wakatime.tasks.cache_coding_activity', 'lang': 'py', 'parent_id': '81f0c7ce-1396-496f-bf64-ae243736c845', 'timelimit': [None, None], 'root_id': '128647cc-f558-4b7d-bafc-338d186b5cfa', 'reply_to': 'e3c2b067-a058-3aa0-a3a1-384d4b917bbf', 'retries': 0, 'expires': None, 'delivery_info': {'exchange': '', 'priority': None, 'routing_key': 'cache', 'redelivered': True}, 'id': '0eba267c-72e4-40ea-91dd-a1a7ab17c514', 'correlation_id': '0eba267c-72e4-40ea-91dd-a1a7ab17c514', 'group': None, 'eta': None, 'kwargsrepr': "{'cache_projects': True, 'timeout': 15, 'user_id': UUID('d9c69ce0-f194-45a6-83cf-98f931fca8aa'), 'writes_only': False}", 'origin': 'gen3021<strong i="12">@worker02</strong>'}, '[[], {"cache_projects": true, "timeout": 15, "user_id": "d9c69ce0-f194-45a6-83cf-98f931fca8aa", "writes_only": false}, {"callbacks": null, "chain": null, "chord": null, "errbacks": null}]', 'application/json', 'utf-8') kwargs:{})
[2016-11-27 14:48:11,266: CRITICAL/MainProcess] Unrecoverable error: TypeError("'NoneType' object is not callable",)
Traceback (most recent call last):
  File "./venv/src/celery/celery/worker/worker.py", line 203, in start
    self.blueprint.start(self)
  File "./venv/src/celery/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "./venv/src/celery/celery/bootsteps.py", line 370, in start
    return self.obj.start()
  File "./venv/src/celery/celery/worker/consumer/consumer.py", line 318, in start
    blueprint.start(self)
  File "./venv/src/celery/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "./venv/src/celery/celery/worker/consumer/consumer.py", line 593, in start
    c.loop(*c.loop_args())
  File "./venv/src/celery/celery/worker/loops.py", line 47, in asynloop
    consumer.consume()
  File "./venv/lib/python3.4/site-packages/kombu/messaging.py", line 470, in consume
    self._basic_consume(T, no_ack=no_ack, nowait=False)
  File "./venv/lib/python3.4/site-packages/kombu/messaging.py", line 591, in _basic_consume
    no_ack=no_ack, nowait=nowait)
  File "./venv/lib/python3.4/site-packages/kombu/entity.py", line 737, in consume
    arguments=self.consumer_arguments)
  File "./venv/lib/python3.4/site-packages/amqp/channel.py", line 1578, in basic_consume
    wait=None if nowait else spec.Basic.ConsumeOk,
  File "./venv/lib/python3.4/site-packages/amqp/abstract_channel.py", line 73, in send_method
    return self.wait(wait, returns_tuple=returns_tuple)
  File "./venv/lib/python3.4/site-packages/amqp/abstract_channel.py", line 93, in wait
    self.connection.drain_events(timeout=timeout)
  File "./venv/lib/python3.4/site-packages/amqp/connection.py", line 464, in drain_events
    return self.blocking_read(timeout)
  File "./venv/lib/python3.4/site-packages/amqp/connection.py", line 469, in blocking_read
    return self.on_inbound_frame(frame)
  File "./venv/lib/python3.4/site-packages/amqp/method_framing.py", line 88, in on_frame
    callback(channel, msg.frame_method, msg.frame_args, msg)
  File "./venv/lib/python3.4/site-packages/amqp/connection.py", line 473, in on_inbound_method
    method_sig, payload, content,
  File "./venv/lib/python3.4/site-packages/amqp/abstract_channel.py", line 142, in dispatch_method
    listener(*args)
  File "./venv/lib/python3.4/site-packages/amqp/channel.py", line 1613, in _on_basic_deliver
    fun(msg)
  File "./venv/lib/python3.4/site-packages/kombu/messaging.py", line 617, in _receive_callback
    return on_m(message) if on_m else self.receive(decoded, message)
  File "./venv/src/celery/celery/worker/consumer/consumer.py", line 567, in on_task_received
    callbacks,
  File "./venv/src/celery/celery/worker/strategy.py", line 145, in task_message_handler
    handle(req)
  File "./venv/src/celery/celery/worker/worker.py", line 221, in _process_task_sem
    return self._quick_acquire(self._process_task, req)
  File "./venv/lib/python3.4/site-packages/kombu/async/semaphore.py", line 62, in acquire
    callback(*partial_args, **partial_kwargs)
  File "./venv/src/celery/celery/worker/worker.py", line 226, in _process_task
    req.execute_using_pool(self.pool)
  File "./venv/src/celery/celery/worker/request.py", line 532, in execute_using_pool
    correlation_id=task_id,
  File "./venv/src/celery/celery/concurrency/base.py", line 155, in apply_async
    **options)
  File "./venv/lib/python3.4/site-packages/billiard/pool.py", line 1487, in apply_async
    self._quick_put((TASK, (result._job, None, func, args, kwds)))
TypeError: 'NoneType' object is not callable
[2016-11-27 14:48:11,273: DEBUG/MainProcess] | Worker: Closing Hub...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Worker: Closing Pool...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Worker: Closing Consumer...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Worker: Stopping Consumer...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Consumer: Closing Connection...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Events...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Mingle...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Tasks...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Control...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Gossip...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Closing Heart...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Closing event loop...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Stopping event loop...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Stopping Heart...
[2016-11-27 14:48:11,277: DEBUG/MainProcess] | Consumer: Stopping Gossip...
[2016-11-27 14:48:11,278: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[f786fc75-0518-4893-8988-ff7f063edd12]
[2016-11-27 14:48:11,278: DEBUG/MainProcess] TaskPool: Apply <function _fast_trace_task at 0x7ff469300950> (args:('wakatime.tasks.cache_coding_activity', 'f786fc75-0518-4893-8988-ff7f063edd12', {'argsrepr': '()', 'task': 'wakatime.tasks.cache_coding_activity', 'lang': 'py', 'parent_id': '81f0c7ce-1396-496f-bf64-ae243736c845', 'timelimit': [None, None], 'root_id': '128647cc-f558-4b7d-bafc-338d186b5cfa', 'reply_to': 'e3c2b067-a058-3aa0-a3a1-384d4b917bbf', 'retries': 0, 'expires': None, 'delivery_info': {'exchange': '', 'priority': None, 'routing_key': 'cache', 'redelivered': True}, 'id': 'f786fc75-0518-4893-8988-ff7f063edd12', 'correlation_id': 'f786fc75-0518-4893-8988-ff7f063edd12', 'group': None, 'eta': None, 'kwargsrepr': "{'cache_projects': True, 'timeout': 15, 'user_id': UUID('7056644f-2564-4074-b89e-631973879f44'), 'writes_only': False}", 'origin': 'gen3021<strong i="13">@worker02</strong>'}, '[[], {"cache_projects": true, "timeout": 15, "user_id": "7056644f-2564-4074-b89e-631973879f44", "writes_only": false}, {"callbacks": null, "chain": null, "chord": null, "errbacks": null}]', 'application/json', 'utf-8') kwargs:{})
[2016-11-27 14:48:11,279: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[d5c8dc57-116c-467d-9924-e2999280c2f8]
[2016-11-27 14:48:11,280: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[460ef864-e482-4b0f-8580-d0095750bae6]
[2016-11-27 14:48:11,281: DEBUG/MainProcess] Closed channel #3
[2016-11-27 14:48:11,281: DEBUG/MainProcess] | Consumer: Stopping Control...
[2016-11-27 14:48:11,283: DEBUG/MainProcess] Closed channel #2
[2016-11-27 14:48:11,283: DEBUG/MainProcess] | Consumer: Stopping Tasks...
[2016-11-27 14:48:11,284: DEBUG/MainProcess] Canceling task consumer...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Consumer: Stopping Mingle...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Consumer: Stopping Events...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Consumer: Stopping Connection...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Worker: Stopping Pool...
[2016-11-27 14:48:12,800: DEBUG/MainProcess] result handler: all workers terminated
[2016-11-27 14:48:12,801: DEBUG/MainProcess] | Worker: Stopping Hub...
[2016-11-27 14:48:12,801: DEBUG/MainProcess] | Consumer: Shutdown Heart...
[2016-11-27 14:48:12,802: DEBUG/MainProcess] | Consumer: Shutdown Gossip...
[2016-11-27 14:48:12,802: DEBUG/MainProcess] | Consumer: Shutdown Control...
[2016-11-27 14:48:12,802: DEBUG/MainProcess] | Consumer: Shutdown Tasks...
[2016-11-27 14:48:12,803: DEBUG/MainProcess] Canceling task consumer...
[2016-11-27 14:48:12,803: DEBUG/MainProcess] Closing consumer channel...
[2016-11-27 14:48:12,803: DEBUG/MainProcess] | Consumer: Shutdown Events...
[2016-11-27 14:48:12,804: DEBUG/MainProcess] Closed channel #1
[2016-11-27 14:48:12,805: DEBUG/MainProcess] | Consumer: Shutdown Connection...
[2016-11-27 14:48:12,806: DEBUG/MainProcess] Closed channel #1
[2016-11-27 14:48:12,807: DEBUG/MainProcess] removing tasks from inqueue until task handler finished

Dies wurde mit Celery 4.x eingeführt, da ein Downgrade auf 3.1.24 das Traceback verhindert.

Passiert mir hier unter Linux Python 3.4 nicht. Welche Argumente verwenden Sie, um den Arbeiter zu starten?

_quick_put sollte übrigens niemals None sein. Passiert das beim Start oder immer nach einem Verbindungsabbruch?

Ich habe versucht zu reproduzieren, indem ich den Broker stoppte, während ich Aufgaben ausführte, und hatte immer noch kein Glück bei der Reproduktion.

Immer beim Start. Die Arbeiterargumente sind:

/opt/app/venv/bin/python /opt/app/venv/bin/celery worker --app=wakatime.celery --workdir=/opt/app --logfile=/var/log/celery/worker.log --loglevel=INFO --concurrency=50 --exclude-queues=medium,low,cache

👍 dafür. Immer das gleiche Problem, sogar auf 4.0.1

@ask Ich kann es jedes Mal reproduzieren, wenn Sie Nachrichten auf dem Broker haben, die darauf warten, verarbeitet zu werden, wenn der Arbeiter auftaucht. Dies ist oft der Fall, wenn ich Beat verwende, was bei mir der Fall ist. Wenn die Beat-Dienste vor dem Worker online gehen, können Sie den Worker aufgrund des oben genannten Problems nicht starten. Ich verwende Python 2.7 für alle diese Angelegenheiten und kann es konsistent reproduzieren.

Dies ist derselbe Fehler wie der in #3539 erwähnte

@jmesquita das stimmt mit meinem Szenario überein, da meine Warteschlangen beim Starten der Worker immer ausstehende Nachrichten auf dem Broker haben.

@alanhamlett Ich versuche, das zu beheben und den Code zu lesen, aber ich bin neu in Sellerie, also könnte es irgendwann dauern. Seltsam für mich ist, dass bei so vielen Menschen, die Sellerie verwenden und Sellerienachrichten standardmäßig in die Warteschlange der Arbeiter gestellt werden, dies innerhalb der Community nicht explodiert ist. Ich frage mich, ob ich es irgendwie missbrauche.

Ich habe mich ein wenig mit dem Code beschäftigt, _quick_put wird von AsyncPool._create_write_handlers zugewiesen, was von AsyncPool.register_with_event_loop aufgerufen wird, was wiederum von celery.worker.loops.asynloop aufgerufen wird. Oberflächlich betrachtet scheint das Problem zu sein, dass asynloop zuerst consumer.consume() anruft und erst dann obj.register_with_event_loop anruft, was dazu führt, dass _quick_put wenn None wird es wird innerhalb von consume() aufgerufen.

Dies würde erklären, warum die Probleme nicht auftreten, wenn sich beim Start der Ereignisschleife keine Nachrichten in der Warteschlange befinden, da consume() dann nichts tut und beim nächsten Aufruf register_with_event_loop tut wurden schon angerufen.

Das konnte ich durch Umzug beheben

obj.controller.register_with_event_loop(hub)
obj.register_with_event_loop(hub)

vor consumer.consume() , obwohl dies natürlich nur eine sehr naive (und möglicherweise falsche) Lösung ist.

Also habe ich mein Problem umgangen, indem ich Sellerie-Beat-Nachrichten transient gemacht habe, was eigentlich sowieso mein beabsichtigtes Verhalten ist. Ich werde darauf zurückkommen, sobald ich etwas mehr Erfahrung mit Sellerie und seiner Codebasis habe.

@jmesquita :

Also habe ich mein Problem umgangen, indem ich Sellerieschlagnachrichten vorübergehend gemacht habe

Das verhindert, dass der Fehler auftritt. Vielen Dank für den Vorschlag.

Ich kann diesen Fehler nur reproduzieren, wenn ich versuche, aus mehreren Warteschlangen zu konsumieren. Wenn alles aus einer einzigen Warteschlange konsumiert wird, funktioniert der Start wie erwartet (Nachrichten in der Warteschlange werden ordnungsgemäß konsumiert).

@adewes Ich habe Ihren Lösungsvorschlag getestet und zumindest oberflächlich scheint er das Problem zu lösen.

@adewes Können Sie eine Pull-Anfrage stellen, damit wir Ihre vorgeschlagene Änderung besprechen können?

Gibt es Neuigkeiten zu diesem Thema? Das bereitet uns jetzt große Probleme, auch in der Produktion. Ich kann nicht einmal lokal testen, weil ich das Problem TypeError bekomme. Möglicherweise müssen wir auf Sellerie 3 zurückstufen.

Ich konnte es bisher nicht lösen, auch vorerst auf Version 3 heruntergestuft, hoffe das Problem wird bald behoben. @thedrow meine "schnelle Lösung" hat keine vollständige Lösung des Problems ergeben, daher öffne ich keine Pull-Anfrage. Ich bin mit dem Datenfluss der verwendeten Komponenten nicht ganz vertraut (hier sind mehrere Bibliotheken im Spiel), daher kann ich dies derzeit leider nicht weiter debuggen.

Ich bin mir nicht einmal sicher, ob wir ein Downgrade durchführen können, da wir uns möglicherweise auf die neue Verwendung von Nachrichtenheadern im v2-Aufgabendesign verlassen.

@ask--Ich freue mich über eine Bildschirmfreigabe oder was auch immer mit Ihnen, damit Sie meine genaue Umgebung sehen können, um beim Debuggen zu helfen, vielleicht sogar versuchen, ein Remote-Debugging zu öffnen, wenn wir müssen. Wir stecken ein bisschen in der Klemme, weil wir bei Celery 4 All-in gegangen sind und jetzt unsere Arbeiter nicht in die Produktion aufnehmen können.

Im Moment können Sie meinen Fork installieren, um die Dinge in Ihrer Produktionsumgebung zum Laufen zu bringen:

pip install -e git://github.com/alanhamlett/celery.git@73147a9da31f2932eb4778e9474fbe72f23d21c2#egg=Celery

Ich habe gerade #3752 geöffnet, um dies zu beheben, muss aber zuerst einen guten Test finden, um den Fehler zu beheben.

Vielen Dank.

Ich fange an zu glauben, dass ich verrückt werde ... Ich habe versucht, auf 4.0.2 (derzeit auf 4.0.0) zu aktualisieren, und mit diesem Upgrade funktionierte plötzlich auch self.retry() nicht mehr.

Das explizite Angeben von Warteschlangen in der CLI sieht aus wie ein Spaziergang (auf 4.0.0)

Wir geben die Warteschlangen explizit in der CLI an; wir hatten das Problem immer noch.

Am Freitag, 13. Januar 2017 um 5:35 Uhr, Karol Duleba [email protected]
schrieb:

Das explizite Angeben von Warteschlangen in der CLI sieht aus wie ein Spaziergang (on
4.0.0)

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/celery/celery/issues/3620#issuecomment-272412258 , oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ABRHQSzvyRcQI5qvfufNwPJvXNElcQKPks5rR1NggaJpZM4K7LEz
.

@jdotjdot - Ich sehe dasselbe. Angeben von Warteschlangen in der Befehlszeile.
Ich sehe das Problem nur, wenn sich Daten in der Warteschlange befinden. Wenn die Warteschlangen leer sind, kann ich Worker starten und sie werden ausgeführt.

+1

Habe genau dieses Problem. Die einzige Lösung scheint das Zurücksetzen meines Brokers zu sein (was für eine Warteschlange nicht gut ist).

+1

Nach #3773, Mangel an grundlegenden Funktionen und Überkomplexität werde ich Celery wahrscheinlich durch https://github.com/closeio/tasktiger ersetzen. Will jemand #3752 übernehmen? Alles, was Sie brauchen, ist einen Test zu schreiben, um das Problem abzudecken.

@alanhamlett Tasktiger war mir nicht bekannt, aber es sieht vielversprechend aus. Wissen Sie, wie ausgereift/stabil/zuverlässig es ist? Normalerweise bin ich ein großer Fan von Mikro-Frameworks, und jetzt ist Celery enorm gewachsen, mit mehreren externen Abhängigkeiten + Umstellung auf Python3 ... die Dinge scheinen außer Kontrolle zu geraten (zumindest bei meinen Bereitstellungen).

Wenn man bedenkt, dass es in PR #3752 bereits einen Fix gibt, was sind die Pläne, diesen zu veröffentlichen? Bitte beachten Sie, dass dies ein kritischer Fehler ist, da er jede Produktionsumgebung daran hindert, Celery 4.x zu verwenden. Sie können nicht zulassen, dass Arbeiter sterben, nur weil ausstehende Nachrichten eingehen.

Würde das auch gerne zusammengelegt sehen

Da die Kurzlebigkeit der Arbeitnehmer für Celery so grundlegend ist, kann ich mir nicht vorstellen, dass es zu viele andere Probleme gibt, die eine höhere Priorität verdienen als dieses. Das ist das einzige, was uns daran hindert, zu Prod zu gehen. Hat irgendjemand da draußen eine Einschätzung, wann es angegangen wird?

@johnatron Ich dachte dasselbe, stieß aber auf mehrere andere neu eingeführte Fehler in Prod. Musste heruntergestuft werden, was schwierig ist, da die Messaging-Spezifikation zwischen 3.x und 4.x nicht kompatibel ist. Ich habe mich auch nach Alternativen zu Sellerie umgesehen, wie zum Beispiel tasktiger . Seien Sie vorsichtig mit Sellerie 4.xx in Prod.

Die Nachrichtenspezifikation ist mit der neuesten Version von 3.x kompatibel.

Ich gebe zu, ich bin ziemlich erstaunt, dass dies nicht angesprochen wurde. Ich benutze
Alans Gabel gerade in Produktion.

Am Montag, 13. Februar 2017 um 14:05 Uhr, Alan Hamlett [email protected]
schrieb:

@johnatron https://github.com/johnatron Ich dachte dasselbe, aber
stieß auf mehrere andere neu eingeführte Fehler in Prod. musste downgraden,
Das ist schwierig, da die Messaging-Spezifikation nicht zwischen 3.x kompatibel ist
und 4.x. Hat mich auch dazu gebracht, nach Alternativen zu Sellerie zu suchen, wie Tasktiger
https://github.com/closeio/tasktiger . Seien Sie vorsichtig mit Sellerie 4.xx in
Prod.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/celery/celery/issues/3620#issuecomment-279489134 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ABRHQZkHixjDu37IA7PbAW6iJYcVTGevks5rcKligaJpZM4K7LEz
.

Angesichts dieser unglücklichen Verzögerung habe ich beschlossen, einige Fixes für bekannte Celery 4-Probleme in git+http://github.com/Eugeny/celery#egg=celery==4.0.2.1 zusammenzuführen
Das beinhaltet:

• @alanhamletts Lösung für dieses Problem
• Der Fix von @HealthTechDevelopers für den Zeitplan von django-celery-beat wird nicht neu geladen

Funktioniert bisher in der Produktion einwandfrei

Die Nachrichtenspezifikation ist möglicherweise kreuzkompatibel, aber es gibt (subtile) inkompatible Unterschiede zwischen den Versionen, wenn es um Sellerie-Leinwand und Verkettung geht (eine Funktion, die wir häufig verwenden). Es wurde viel Aufwand betrieben, um unsere App von v3 auf v4 zu portieren. Zurückgehen zu müssen, wäre eine schlechte Zeit.

O fauler Tag! Danke.

Ich habe das gleiche Problem mit Python 3.6 und Sellerie 4.0.2.

Beenden Sie Sellerie, erstellen Sie eine Aufgabe, starten Sie Sellerie und erhalten Sie sofort den Fehler TypeError: 'NoneType' object is not callable . @Fragen , könnten Sie bitte die vorgeschlagenen Korrekturen und Zusammenführungen in Betracht ziehen? Dies hindert zuvor glückliche Benutzer von Sellerie daran, Sellerie weiterhin zu verwenden :(

Danke für deine Zeit, @ask!

„Microsoft Windows wird nicht mehr unterstützt.

Die Testsuite wird bestanden und Celery scheint mit Windows zu funktionieren, aber wir geben keine Garantien, da wir Probleme auf dieser Plattform nicht diagnostizieren können. Wenn Sie ein Unternehmen sind, das Unterstützung auf dieser Plattform benötigt, wenden Sie sich bitte an uns."
Wird wohl nicht behoben.

@tiptoettt Dies ist kein Windows-spezifisches Problem. Ich bin auf Mac. Können Sie sich bitte alle Kommentare genau ansehen? Entwickler werden Celery aus diesem Grund fallen lassen. Ich habe Sellerie für 5 Jahre verwendet und es ist ein großes Problem. Ich werde eine frühere Version 3.1.25 verwenden, wenn dieses Problem nicht auftritt.

Habe auch dieses Problem

lpiner<strong i="6">@host</strong>:~$ uname -a
Linux host 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

lpiner<strong i="9">@host</strong>:~$ celery --version
4.0.2 (latentcall)

Dies ist die Codezeile, die das Problem zu verursachen scheint:

task_queues = (
    Queue('queue1_name', Exchange('default'), routing_key='default'),
    Queue('queue2_name', Exchange('default'), routing_key='general.routing_key'),
)

Durch das Entfernen der zweiten Warteschlange wird das Problem behoben.

Nach dem, was ich aus dem Post von @ChillarAnand in celery/kombu/issues/675 verstehe, sollte dieses Problem mit 4.0.3 gelöst sein, richtig?

Ich habe dieses Problem nicht mehr gesehen, seit ich angefangen habe, vom Master-Zweig aus zu bauen.

Am 8. Mai 2017 um 17:58 Uhr schrieb „Victor“ [email protected] :

Soweit ich das von @ChillarAnand verstehe
https://github.com/ChillarAnand 's post in celery/kombu#675
https://github.com/celery/kombu/issues/675 , dieses Problem sollte behoben sein
von 4.0.3, richtig?

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/celery/celery/issues/3620#issuecomment-300002736 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AC3sA400hzoX7V0GUrUSfYmry9SZ8eIRks5r34_pgaJpZM4K7LEz
.

Danke, es hat funktioniert!

Ich hatte das gleiche Problem auf Celery 3.1.23 (Cipater) mit RabbitMQ. Nach langem Debuggen habe ich endlich diesen Thread gefunden und das Problem mit der Version 3.1.25 behoben. Aber es schlug wirklich mit dem Kopf gegen die Wand.

Dasselbe Problem bei v4.0.2 (latentcall) mit mehreren Warteschlangen + Heartbeat.

Das gleiche Problem für mich bei v0.4.0.2 Workaround ist ein Downgrade auf v3.x

v4.0.2
Für mich ist dieses Thema ein Showstopper. Ich denke nicht an ein Downgrade auf 3.x. Ich hoffe, dass die neue Version bald veröffentlicht wird.

@ba1dr Build vom Meister. Das behebt es für mich.

@LPiner , danke, das hat das Problem für mich behoben. Aber das ist keine produktionsreife Lösung, oder?

@ba1dr keine große Auswahl TBH. Es ist entweder dies oder ein Downgrade zurück auf 3.x.
Wir verwenden es ohne Probleme in der Produktion, aber unsere Größenordnung beträgt nur wenige hundert Jobs pro Tag, Ihre Laufleistung kann variieren.

Wir werden bald veröffentlichen. Siehe #4109

Auch hier betroffen. Schlagen Sie uns einfach an. Bereit für die Veröffentlichung!