Celery: Celery Worker travando após a primeira tarefa com TypeError: o objeto 'NoneType' não pode ser chamado

O erro está se repetindo no log porque o daemon do trabalhador Celery está travando, então o systemd o reinicia.

@ask , self._quick_put de alguma forma não está definido. O bilhar deve verificar um None antes de pagar, pegar a exceção, ou self._quick_put nunca deve ser None ?

Quando eu mudo billiard/pool.py#L1483 para if self.threads or self._quick_put is None: Celery não trava mais, mas por algum motivo os trabalhadores nunca processam nenhuma tarefa.

Saída mais detalhada com nível de log 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

Isso foi introduzido com o Celery 4.x porque o downgrade para 3.1.24 impede o rastreamento.

Não acontece comigo aqui no Linux Python 3.4. Que argumentos você usa para iniciar o trabalhador?

_quick_put nunca deve ser Nenhum. Isso acontece na inicialização ou sempre após uma falha de conexão?

Eu tenho tentado reproduzir parando o corretor durante a execução de tarefas e ainda sem sorte na reprodução.

Sempre na inicialização. Os argumentos do trabalhador são:

/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

👍 para isso. Obtendo o mesmo problema, mesmo em 4.0.1

@ask Eu consigo reproduzi-lo toda vez que você tiver mensagens no broker esperando para serem processadas quando o trabalhador aparecer. Este é frequentemente o caso ao usar o beat, que é o meu caso. Se os serviços de batida ficarem online antes do trabalhador, você não poderá iniciar o trabalhador devido ao problema mencionado acima. Estou usando o python 2.7 para todo esse assunto e sou capaz de reproduzi-lo de forma consistente.

Este é o mesmo erro mencionado em #3539

@jmesquita isso é consistente com meu cenário, pois minhas filas sempre tem mensagens pendentes no broker ao iniciar os workers.

@alanhamlett Estou tentando consertar isso e lendo o código, mas sou novo no aipo, então pode levar algum tempo. O que é estranho para mim é que com tantas pessoas usando aipo e mensagens de aipo sendo enfileiradas por padrão para os trabalhadores, isso não explodiu dentro da comunidade. Me faz pensar se estou usando mal de alguma forma.

Pesquisei um pouco no código, _quick_put é atribuído por AsyncPool._create_write_handlers , que é chamado por AsyncPool.register_with_event_loop , que é chamado por celery.worker.loops.asynloop . Superficialmente, o problema parece ser que asynloop primeiro chama consumer.consume() e só então chama obj.register_with_event_loop , o que faz com que _quick_put seja None quando ele é chamado de dentro de consume() .

Isso explicaria por que os problemas não ocorrem quando não há mensagens na fila quando o loop de eventos é iniciado, pois consume() não fará nada e na próxima vez que for chamado, register_with_event_loop já foram chamados.

Eu poderia consertar isso movendo

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

antes consumer.consume() , embora isso seja apenas uma correção muito ingênua (e possivelmente errada).

Então resolvi meu problema tornando as mensagens de batida de aipo transitórias, que na verdade é o meu comportamento pretendido de qualquer maneira. Vou revisitar isso assim que tiver um pouco mais de experiência com o aipo e sua base de código.

@jmesquita :

Então resolvi meu problema tornando as mensagens de batida de aipo transitórias

Isso evita que o erro ocorra. Obrigado pela sugestão.

Só posso reproduzir esse bug se estiver tentando consumir de várias filas. Se tudo for consumido de uma única fila, a inicialização funcionará conforme o esperado (as mensagens na fila são consumidas corretamente).

@adewes Eu testei sua solução proposta e, pelo menos na superfície, parece resolver o problema.

@adewes Você pode emitir um pull request para que possamos discutir sua proposta de mudança?

Existem atualizações sobre este assunto? Isso está nos causando grandes problemas agora, inclusive na produção. Não consigo nem testar localmente porque recebo o problema TypeError . Talvez tenhamos que fazer o downgrade de volta para o Aipo 3.

Não consegui resolver até agora, também fiz downgrade para a versão 3 por enquanto, espero que o problema seja corrigido em breve. @thedrow minha "solução rápida" não rendeu uma resolução completa do problema, então não estou abrindo uma solicitação de pull. Eu não sou totalmente versado no fluxo de dados dos componentes usados ​​(existem várias bibliotecas em jogo aqui), então não posso depurar isso agora, infelizmente.

Na verdade, nem tenho certeza de que podemos fazer o downgrade porque é possível que estejamos contando com o novo uso de cabeçalhos de mensagem no design da tarefa v2.

@ask--Estou feliz em compartilhar a tela ou qualquer outra coisa com você para que você possa ver meu ambiente exato para ajudar a depurar, talvez até tente abrir uma depuração remota, se necessário. Estamos em apuros porque apostamos tudo no Aipo 4 e agora não podemos iniciar nossos trabalhadores na produção.

Por enquanto, você pode instalar meu fork para que as coisas funcionem em seu ambiente de produção:

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

Acabei de abrir o #3752 para corrigir isso, mas preciso descobrir um bom teste para cobrir o bug primeiro.

Muito obrigado.

Começando a pensar que estou ficando louco... Tentei atualizar para 4.0.2 (atualmente em 4.0.0) e com essa atualização, de repente self.retry() parou de funcionar também.

Especificar filas explicitamente na CLI parece um passeio (no 4.0.0)

Especificamos as filas explicitamente na CLI; ainda tínhamos o problema.

Em sex, 13 de janeiro de 2017 às 5h35, Karol Duleba [email protected]
escrevi:

Especificar filas explicitamente na CLI parece um passeio (no
4.0.0)

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/celery/celery/issues/3620#issuecomment-272412258 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/ABRHQSzvyRcQI5qvfufNwPJvXNElcQKPks5rR1NggaJpZM4K7LEz
.

@jdotjdot - estou vendo a mesma coisa. Especificando filas na linha de comando.
Só vejo o problema quando há dados na fila. Se as filas estiverem vazias, posso iniciar os trabalhadores e eles serão executados.

+1

Tendo esse problema exato. A única solução parece ser redefinir meu corretor (o que não é bom para uma fila).

+1

Depois disso, #3773, falta de recursos básicos e excesso de complexidade, provavelmente substituirei o Celery por https://github.com/closeio/tasktiger. Alguém quer assumir o #3752? Tudo que você precisa é escrever um teste para cobrir o problema.

@alanhamlett Eu não conhecia o tasktiger, mas parece promissor. Você sabe o quão maduro/estável/confiável ele é? Geralmente sou um grande fã de micro-frameworks, e agora o Celery cresceu enormemente, com várias dependências externas + alternância para Python3... as coisas parecem ficar fora de controle (pelo menos nas minhas implantações).

Considerando que já existe uma correção no PR #3752, quais são os planos para liberar isso? Observe que este é um bug crítico porque impede que qualquer ambiente de produção use o Celery 4.x. Você não pode ter trabalhadores morrendo só porque há mensagens pendentes chegando.

Gostaria de ver isso mesclado também

Com a natureza efêmera dos trabalhadores sendo tão fundamental para o aipo, não consigo imaginar que existam muitas outras questões que mereçam uma prioridade maior do que esta. Esta é a única coisa que nos impede de ir para Prod. Alguém aí tem uma estimativa de quando será abordado?

@johnatron Eu pensei a mesma coisa, mas encontrei vários outros bugs recém-introduzidos no Prod. Tive que fazer downgrade, o que é difícil porque a especificação de mensagens não é compatível entre 3.xe 4.x. Também me fez procurar alternativas ao aipo, como tasktiger . Tenha cuidado com o aipo 4.xx em Prod.

A especificação da mensagem é compatível com a versão mais recente do 3.x.

Admito que estou bastante surpreso que isso não tenha sido abordado. estou a usar
O garfo de Alan agora em produção.

Em segunda-feira, 13 de fevereiro de 2017 às 14h05, Alan Hamlett [email protected]
escrevi:

@johnatron https://github.com/johnatron pensei a mesma coisa, mas
encontrou vários outros bugs recém-introduzidos no Prod. Teve que rebaixar,
o que é difícil porque a especificação de mensagens não é compatível entre 3.x
e 4.x. Também me fez procurar alternativas ao aipo, como tasktiger
https://github.com/closeio/tasktiger . Tenha cuidado com o Aipo 4.xx em
Prod.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/celery/celery/issues/3620#issuecomment-279489134 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/ABRHQZkHixjDu37IA7PbAW6iJYcVTGevks5rcKligaJpZM4K7LEz
.

À luz desse atraso infeliz, decidi mesclar algumas correções para problemas conhecidos do Celery 4 em git+http://github.com/Eugeny/celery#egg=celery==4.0.2.1
Isso inclui:

• Correção do @alanhamlett para este problema
• Correção do @HealthTechDevelopers para o cronograma django-celery-beat não ser recarregado

Funcionando bem na produção até agora

A especificação da mensagem pode ser compatível, mas existem diferenças (sutis) incompatíveis entre as versões quando se trata de Celery Canvas e encadeamento (um recurso que usamos muito). Um esforço considerável foi feito para portar nosso aplicativo da v3 para a v4. Ter que voltar seria um mau momento.

Ó dia de framboesa! Obrigada.

Eu tenho esse mesmo problema usando Python 3.6 e aipo 4.0.2.

Desligue o aipo, crie uma tarefa, inicie o aipo e imediatamente receba o erro TypeError: 'NoneType' object is not callable . @ask , você poderia considerar as correções propostas e a fusão? Isso está impedindo que usuários anteriormente felizes do aipo continuem usando o aipo :(

Obrigado pelo seu tempo, @ask!

"O Microsoft Windows não é mais suportado.

O conjunto de testes está sendo aprovado e o Celery parece estar funcionando com o Windows, mas não oferecemos garantias, pois não conseguimos diagnosticar problemas nesta plataforma. Se você é uma empresa que precisa de suporte nesta plataforma, entre em contato."
Provavelmente não será corrigido.

@tiptoettt este não é um problema específico do Windows. Estou no Mac. Você pode, por favor, olhar atentamente para os comentários de todos? Os desenvolvedores vão abandonar o aipo por causa disso. Eu usei aipo por 5 anos e é um grande problema. Vou usar uma versão anterior 3.1.25 se não tiver esse problema.

Também to com esse problema

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)

Esta é a linha de código que parece causar o problema:

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

A remoção da segunda fila faz com que o problema desapareça.

Pelo que entendi do post de @ChillarAnand em aipo/kombu/issues/675, esse problema deve ser resolvido pelo 4.0.3, certo?

Não vejo esse problema desde que comecei a construir a partir do branch master.

Em 8 de maio de 2017, 17h58, "Victor" [email protected] escreveu:

Pelo que entendi de @ChillarAnand
https://github.com/ChillarAnand's post in celery/kombu#675
https://github.com/celery/kombu/issues/675 , este problema deve ser resolvido
por 4.0.3, certo?

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/celery/celery/issues/3620#issuecomment-300002736 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AC3sA400hzoX7V0GUrUSfYmry9SZ8eIRks5r34_pgaJpZM4K7LEz
.

Obrigado, funcionou!

Eu tive o mesmo problema no Celery 3.1.23 (Cipater) usando o RabbitMQ. Após uma longa depuração, finalmente encontrei este tópico e corrigi o problema usando a versão 3.1.25. Mas estava batendo a cabeça contra a parede, realmente.

Mesmo problema em v4.0.2 (latentcall) com várias filas + pulsação.

mesmo problema para mim na solução alternativa v0.4.0.2 é fazer o downgrade para v3.x

v4.0.2
Para mim esta questão é um espetáculo. Eu não considero fazer downgrade para 3.x. Espero que a nova versão seja lançada em breve.

@ba1dr compilação do mestre. Isso resolve para mim.

@LPiner , obrigado, isso corrigiu o problema para mim. Mas esta não é uma solução pronta para produção, hein?

@ba1dr não tem muita escolha TBH. É isso ou downgrade de volta para 3.x.
Nós o usamos na produção sem problemas, mas nossa escala é de apenas algumas centenas de trabalhos por dia, sua milhagem pode variar.

Vamos liberar em breve. Veja #4109

Afetado aqui também. Basta nos bater. Pronto para o lançamento!