You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
aiokafka relies on ioloop.create_task() method, which run coroutine in background and makes it "cancelable". The problem that the tasks list in asyncio is public and external code can cancel sender_task. After that Producer will be in the state, when any message will be successfully added to message_accumulator, but will never actually sent by Sender.
Originally I faced with this problem when using AsyncTestCase from Tornado. After each test, Tornado cancels all running background tasks. It's could be questionable how legal this behavior, but the fact is that only the public APIs are used by Tornado and there are no errors or exceptions are logged from aiokafka side. It just hangs up forever on the second and next tests.
I haven't digged in other circumstances when background asyncio tasks could be canceled by third-party libs, but if this happens there should be some sort of exception or error logging.
Expected behaviour
I expect the Sender recover after stop either Producer raise an error what sender_task is canceled and message will never delivered.
Environment (please complete the following information):
aiokafka relies on
ioloop.create_task()
method, which run coroutine in background and makes it "cancelable". The problem that the tasks list in asyncio is public and external code can cancelsender_task
. After thatProducer
will be in the state, when any message will be successfully added tomessage_accumulator
, but will never actually sent bySender
.Originally I faced with this problem when using
AsyncTestCase
from Tornado. After each test, Tornado cancels all running background tasks. It's could be questionable how legal this behavior, but the fact is that only the public APIs are used by Tornado and there are no errors or exceptions are logged from aiokafka side. It just hangs up forever on the second and next tests.I haven't digged in other circumstances when background asyncio tasks could be canceled by third-party libs, but if this happens there should be some sort of exception or error logging.
Expected behaviour
I expect the
Sender
recover after stop eitherProducer
raise an error whatsender_task
is canceled and message will never delivered.Environment (please complete the following information):
Reproducible example
The text was updated successfully, but these errors were encountered: