search

Polyconseil / aioamqp

AMQP implementation using asyncio
Other
280 stars 88 forks source link

asyncio.streams.IncompleteReadError: 0 bytes read on a total of 7 expected bytes during close #135

Open a-urth opened 7 years ago

a-urth commented 7 years ago

After updating to 0.9.0 version to avoid the problem with server closed connection close operation I've noticed that following error always occurs after protocol close operation. Seems that protocol run is called shortly after closing.

Traceback (most recent call last):
  File "/Users/free2use/.pyenv/versions/wiki_api_3.6.0/lib/python3.6/site-packages/aioamqp/frame.py", line 412, in read_frame
    data = yield from self.reader.readexactly(7)
  File "/Users/free2use/.pyenv/versions/3.6.0/lib/python3.6/asyncio/streams.py", line 666, in readexactly
    raise IncompleteReadError(incomplete, n)
asyncio.streams.IncompleteReadError: 0 bytes read on a total of 7 expected bytes

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/free2use/.pyenv/versions/wiki_api_3.6.0/lib/python3.6/site-packages/aioamqp/protocol.py", line 304, in run
    yield from self.dispatch_frame()
  File "/Users/free2use/.pyenv/versions/wiki_api_3.6.0/lib/python3.6/site-packages/aioamqp/protocol.py", line 251, in dispatch_frame
    frame = yield from self.get_frame()
  File "/Users/free2use/.pyenv/versions/wiki_api_3.6.0/lib/python3.6/site-packages/aioamqp/protocol.py", line 235, in get_frame
    yield from frame.read_frame()
  File "/Users/free2use/.pyenv/versions/wiki_api_3.6.0/lib/python3.6/site-packages/aioamqp/frame.py", line 414, in read_frame
    raise exceptions.AmqpClosedConnection() from ex
aioamqp.exceptions.AmqpClosedConnection

I'm seeing because of on_error callback in which I catch and log all possible amqp errors.

Is this desired behavior?

RemiCardona commented 7 years ago

Well, it's not so much called as it's already running as a Task when the handshake is done.

Given the current "error handling" code, yes this behavior looks correct. TBH, we don't use on_error callbacks in our production code. The whole thing needs to be reworked…

a-urth commented 7 years ago

Thanks for answer, makes sense now.