Celery: Pekerja Seledri mogok setelah tugas pertama dengan TypeError: objek 'NoneType' tidak dapat dipanggil

Kesalahan berulang di log karena daemon pekerja Celery mogok, jadi systemd memulai ulang.

@ask , self._quick_put entah bagaimana tidak didefinisikan. Haruskah biliar memeriksa nilai None sebelum menelepon, menangkap pengecualian, atau haruskah self._quick_put tidak pernah menjadi None ?

Ketika saya mengubah billiard/pool.py#L1483 menjadi if self.threads or self._quick_put is None: Seledri tidak mogok lagi tetapi untuk beberapa alasan pekerja tidak pernah memproses tugas apa pun.

Lebih banyak keluaran verbose dengan tingkat logging 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

Ini diperkenalkan dengan Seledri 4.x karena menurunkan versi ke 3.1.24 mencegah traceback.

Tidak terjadi pada saya di sini di Linux Python 3.4. Argumen apa yang Anda gunakan untuk memulai pekerja?

_quick_put tidak boleh menjadi None btw. Apakah ini terjadi saat startup atau selalu setelah kegagalan koneksi?

Saya sudah mencoba mereproduksi dengan menghentikan broker saat menjalankan tugas, dan masih belum berhasil mereproduksi.

Selalu saat startup. Argumen pekerja adalah:

/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

👍 untuk ini. Mendapatkan masalah yang sama, bahkan pada 4.0.1

@ask Saya dapat mereproduksinya setiap kali Anda memiliki pesan di broker yang menunggu untuk diproses ketika pekerja muncul. Ini sering terjadi saat menggunakan beat, yang merupakan kasus saya. Jika layanan beat online sebelum pekerja, Anda tidak akan dapat memulai pekerja karena masalah yang disebutkan di atas. Saya menggunakan python 2.7 untuk semua itu dan saya dapat mereproduksinya secara konsisten.

Ini adalah kesalahan yang sama seperti yang disebutkan di #3539

@jmesquita itu konsisten dengan skenario saya, karena antrian saya selalu memiliki pesan tertunda di broker saat memulai pekerja.

@alanhamlett Saya mencoba untuk memperbaikinya dan membaca kodenya tetapi saya baru mengenal seledri jadi mungkin perlu waktu. Apa yang aneh bagi saya adalah bahwa dengan begitu banyak orang yang menggunakan seledri dan pesan seledri yang diantrekan secara default ke pekerja, ini tidak meledak di dalam komunitas. Membuat saya bertanya-tanya apakah saya menyalahgunakannya entah bagaimana.

Saya menggali kodenya sedikit, _quick_put ditugaskan oleh AsyncPool._create_write_handlers , yang dipanggil oleh AsyncPool.register_with_event_loop , yang dipanggil oleh celery.worker.loops.asynloop . Secara dangkal, masalahnya tampaknya asynloop pertama kali memanggil consumer.consume() dan baru kemudian memanggil obj.register_with_event_loop , yang menyebabkan _quick_put menjadi None ketika itu dipanggil dari dalam consume() .

Ini akan menjelaskan mengapa masalah tidak terjadi ketika tidak ada pesan dalam antrian saat loop acara dimulai, karena kemudian consume() tidak akan melakukan apa-apa dan saat berikutnya dipanggil, register_with_event_loop akan sudah dipanggil.

Saya bisa memperbaikinya dengan memindahkan

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

sebelum consumer.consume() , meskipun ini tentu saja hanya perbaikan yang sangat naif (dan mungkin salah).

Jadi saya mengatasi masalah saya dengan membuat pesan celery beat sementara, yang sebenarnya merupakan perilaku yang saya maksudkan. Saya akan meninjau kembali ini segera setelah saya memiliki sedikit lebih banyak pengalaman dengan Seledri dan basis kodenya.

@jmesquita :

Jadi saya mengatasi masalah saya dengan membuat pesan seledri mengalahkan sementara

Itu mencegah kesalahan terjadi. Terima kasih atas sarannya.

Saya hanya dapat mereproduksi bug ini jika saya mencoba mengkonsumsi dari beberapa antrian. Jika semuanya dikonsumsi dari satu antrian maka start up berfungsi seperti yang diharapkan (pesan pada antrian dikonsumsi dengan benar).

@adewes Saya menguji solusi yang Anda usulkan dan setidaknya di permukaan tampaknya menyelesaikan masalah.

@adewes Bisakah Anda mengeluarkan permintaan tarik sehingga kami dapat mendiskusikan perubahan yang Anda usulkan?

Apakah ada pembaruan tentang masalah ini? Ini menyebabkan masalah besar bagi kami sekarang, termasuk dalam produksi. Saya bahkan tidak dapat menguji secara lokal karena saya mendapatkan masalah TypeError . Kami mungkin harus menurunkan versi kembali ke Seledri 3.

Saya tidak dapat menyelesaikannya sejauh ini, juga diturunkan ke versi 3 untuk saat ini, semoga masalahnya segera diperbaiki. @thedrow "perbaikan cepat" saya tidak menghasilkan penyelesaian masalah yang lengkap, jadi saya tidak membuka permintaan tarik. Saya tidak sepenuhnya berpengalaman dalam aliran data komponen yang digunakan (ada beberapa perpustakaan yang dimainkan di sini), jadi sayangnya saya tidak dapat men-debug ini lebih lanjut sekarang.

Saya sebenarnya bahkan tidak yakin kami dapat menurunkan versi karena mungkin saja kami mengandalkan penggunaan baru header pesan dalam desain tugas v2.

@ask--Saya senang berbagi layar atau apa pun dengan Anda sehingga Anda dapat melihat lingkungan saya yang tepat untuk membantu debug, bahkan mungkin mencoba membuka debug jarak jauh jika perlu. Kami sedikit terikat karena kami menggunakan Celery 4 dan sekarang tidak dapat memulai pekerja kami dalam produksi.

Untuk saat ini, Anda dapat menginstal garpu saya untuk menjalankan sesuatu di lingkungan prod Anda:

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

Saya baru saja membuka #3752 untuk memperbaikinya, tetapi perlu mencari tahu tes yang baik untuk menutupi bug terlebih dahulu.

Terima kasih banyak.

Mulai berpikir bahwa saya akan gila... Saya mencoba memutakhirkan ke 4.0.2 (saat ini pada 4.0.0) dan dengan pemutakhiran itu, tiba-tiba self.retry() berhenti bekerja juga.

Menentukan antrian secara eksplisit dari dalam CLI terlihat seperti berjalan-jalan (pada 4.0.0)

Kami menentukan antrian secara eksplisit di CLI; kami masih memiliki masalah.

Pada Jumat, 13 Januari 2017 pukul 05.35, Karol [email protected]
menulis:

Menentukan antrian secara eksplisit dari dalam CLI terlihat seperti berjalan-jalan (di
4.0.0)

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/celery/celery/issues/3620#issuecomment-272412258 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/ABRHQSzvyRcQI5qvfufNwPJvXNElcQKPks5rR1NggaJpZM4K7LEz
.

@jdotjdot - Saya melihat hal yang sama. Menentukan antrian pada baris perintah.
Saya hanya melihat masalah ketika ada data dalam antrian. Jika antrian kosong, saya dapat memulai pekerja dan mereka akan berjalan.

+1

Memiliki masalah yang tepat ini. Satu-satunya solusi tampaknya adalah mengatur ulang broker saya (yang tidak baik untuk antrian).

+1

Setelah ini, #3773, kurangnya fitur dasar, dan kompleksitas yang berlebihan. Saya mungkin akan mengganti Seledri dengan https://github.com/closeio/tasktiger. Apakah ada yang ingin mengambil alih #3752? Yang Anda butuhkan hanyalah menulis tes untuk membahas masalah ini.

@alanhamlett Saya tidak mengetahui tasktiger, tetapi terlihat menjanjikan. Apakah Anda tahu seberapa matang/stabil/dapat diandalkan itu? Saya biasanya penggemar berat kerangka kerja mikro, dan sekarang Seledri telah tumbuh besar, dengan beberapa dependensi eksternal + peralihan ke Python3...segalanya tampak di luar kendali (setidaknya pada penerapan saya).

Mengingat sudah ada perbaikan di PR #3752, apa rencana untuk merilis ini? Harap dicatat ini adalah bug kritis karena mencegah lingkungan produksi apa pun menggunakan Celery 4.x. Anda tidak dapat membiarkan pekerja mati hanya karena ada pesan tertunda yang masuk.

Ingin melihat ini digabungkan juga

Dengan sifat fana pekerja yang begitu mendasar bagi Celery, saya tidak dapat membayangkan ada terlalu banyak masalah lain yang layak mendapat prioritas lebih tinggi daripada yang satu ini. Ini adalah satu-satunya hal yang menghalangi kami untuk pergi ke Prod. Apakah ada orang di luar sana yang memiliki perkiraan kapan akan ditangani?

@johnatron Saya memikirkan hal yang sama, tetapi mengalami beberapa bug lain yang baru diperkenalkan di Prod. Harus downgrade, yang sulit karena spesifikasi messaging tidak kompatibel antara 3.x dan 4.x. Juga membuat saya melihat alternatif untuk Seledri, seperti tasktiger . Hati-hati dengan Seledri 4.xx di Prod.

Spesifikasi pesan kompatibel dengan versi terbaru 3.x.

Saya akui saya cukup heran ini belum ditangani. saya menggunakan
Garpu Alan sekarang dalam produksi.

Pada Senin, 13 Februari 2017 pukul 14:05, Alan Hamlett [email protected]
menulis:

@johnatron https://github.com/johnatron Saya memikirkan hal yang sama, tapi
mengalami beberapa bug lain yang baru diperkenalkan di Prod. Harus downgrade,
yang sulit karena spesifikasi perpesanan tidak kompatibel antara 3.x
dan 4.x. Juga membuat saya melihat alternatif untuk Seledri, seperti tasktiger
https://github.com/closeio/tasktiger . Hati-hati dengan Seledri 4.xx di
Melecut.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/celery/celery/issues/3620#issuecomment-279489134 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ABRHQZkHixjDu37IA7PbAW6iJYcVTGevks5rcKligaJpZM4K7LEz
.

Mengingat penundaan yang tidak menguntungkan ini, saya memutuskan untuk menggabungkan beberapa perbaikan untuk masalah Seledri 4 yang diketahui bersama-sama di git+http://github.com/Eugeny/celery#egg=celery==4.0.2.1
Ini termasuk:

• Perbaikan @alanhamlett untuk masalah ini
• Perbaikan @HealthTechDevelopers untuk jadwal django-celery-beat tidak dimuat ulang

Bekerja dengan baik dalam produksi sejauh ini

Spesifikasi pesan mungkin kompatibel lintas, tetapi ada perbedaan (halus) yang tidak kompatibel antara versi ketika datang ke Celery Canvas dan chaining (fitur yang sering kami gunakan). Banyak upaya yang dilakukan untuk mem-porting aplikasi kami dari v3 ke v4. Harus kembali akan menjadi waktu yang buruk.

O hari frabjous! Terima kasih.

Saya memiliki masalah yang sama menggunakan Python 3.6 dan seledri 4.0.2.

Matikan seledri, buat tugas, mulai seledri dan segera dapatkan kesalahan TypeError: 'NoneType' object is not callable . @ask, bisakah Anda mempertimbangkan perbaikan dan penggabungan yang diusulkan? Ini mencegah pengguna Seledri yang sebelumnya senang untuk terus menggunakan Seledri :(

Terima kasih atas waktunya, @ask!

"Microsoft Windows tidak lagi didukung.

Rangkaian pengujian sedang berlalu, dan Celery tampaknya berfungsi dengan Windows, tetapi kami tidak memberikan jaminan karena kami tidak dapat mendiagnosis masalah pada platform ini. Jika Anda adalah perusahaan yang membutuhkan dukungan pada platform ini, silakan hubungi."
Mungkin tidak akan diperbaiki.

@tiptoettt ini bukan masalah khusus untuk Windows. Saya di Mac. Bisakah Anda melihat dengan cermat komentar semua orang? Pengembang akan membuang Seledri karena ini. Saya telah menggunakan seledri selama 5 tahun dan ini adalah masalah besar. Saya akan menggunakan versi 3.1.25 sebelumnya jika tidak memiliki masalah ini.

Juga mengalami masalah ini

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)

Ini adalah baris kode yang tampaknya menyebabkan masalah:

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

Menghapus antrean kedua menyebabkan masalah hilang.

Dari apa yang saya pahami dari posting @ChillarAnand di celery/kombu/issues/675, masalah ini harus diselesaikan dengan 4.0.3, bukan?

Saya belum pernah melihat masalah ini sejak saya mulai membangun dari cabang master.

Pada 8 Mei 2017 17:58, "Victor" [email protected] menulis:

Dari apa yang saya pahami dari @ChillarAnand
https://github.com/ChillarAnand posting di seledri/kombu#675
https://github.com/celery/kombu/issues/675 , masalah ini harus diselesaikan
dengan 4.0.3, kan?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/celery/celery/issues/3620#issuecomment-300002736 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AC3sA400hzoX7V0GUrUSfYmry9SZ8eIRks5r34_pgaJpZM4K7LEz
.

Terima kasih, itu berhasil!

Saya memiliki masalah yang sama pada Seledri 3.1.23 (Cipater) menggunakan RabbitMQ. Setelah debugging lama, saya akhirnya menemukan utas ini dan memperbaiki masalah dengan menggunakan versi 3.1.25. Tapi itu membenturkan kepala ke dinding, sungguh.

Masalah yang sama pada v4.0.2 (latentcall) dengan banyak antrian + detak jantung.

masalah yang sama untuk saya tentang solusi v0.4.0.2 adalah menurunkan versi ke v3.x

v4.0.2
Bagi saya masalah ini adalah showstopper. Saya tidak mempertimbangkan untuk menurunkan versi ke 3.x. Saya berharap versi baru akan segera dirilis.

@ba1dr membangun dari master. Itu memperbaikinya untuk saya.

@LPiner , terima kasih, ini memperbaiki masalah saya. Tapi ini bukan solusi siap produksi, kan?

@ba1dr tidak banyak pilihan TBH. Entah ini atau downgrade kembali ke 3.x.
Kami menggunakannya dalam produksi tanpa masalah tetapi skala kami hanya beberapa ratus pekerjaan sehari, jarak tempuh Anda mungkin berbeda.

Kami akan segera rilis. Lihat #4109

Terpengaruh di sini juga. Pukul saja kami. Siap untuk rilis!