Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't seem to capture the ConnectionClosed exception #126

Open
silverdaz opened this issue Jan 7, 2022 · 3 comments
Open

Can't seem to capture the ConnectionClosed exception #126

silverdaz opened this issue Jan 7, 2022 · 3 comments
Labels
question Further information is requested

Comments

@silverdaz
Copy link

silverdaz commented Jan 7, 2022

I'm using the simple consumer example and I get messages from local message broker.

Then I artificially restart the broker.

The frame arrives, gets decoded and the ConnectionClosed exception is created.
However, the code tries to close the connection (and send a CloseOk frame, which won't succeed), but the exceptions are suppressed. The ConnectionClosed itself is passed on, but I don't see where it is raised again.

I'm only getting the following output and no error raised.

Unexpected connection close from remote "amqp://username:******@localhost:5672/%2F", Connection.Close(reply_code=320, reply_text="CONNECTION_FORCED - broker forced connection closure with reason 'shutdown'")
NoneType: None

Note that this is just a print statement, not the exception itself. (I find the NoneType: None suspiciously buggy). After that, no more messages are consumed.

I'd like to capture the ConnectionClosed (and potientially other related ones) and retry the connection (with an exponential backoff) when the broker is restarted.

Am I miss-using the package or am I missing something in the asyncio-loop catching-exception business?
I've tried to put some encompassing try/except but I can't seem to catch the ConnectionClosed exception (although I see it in the logs, when I turn on the debug output. Where does it get swallowed, and why?)

@mosquito
Copy link
Owner

mosquito commented Jan 8, 2022

The simple way to receive this exception is to await the Connection.closing future.

@mosquito mosquito added the question Further information is requested label Jan 8, 2022
@silverdaz
Copy link
Author

Thanks, that seems to do the trick.
I was wondering about the other exceptions that can occur, but that will catch them too.
I have now my "reconnect" loop in case the broker restarts.

I was trying to add a callback to the connection.closing too, and call connect again, but it was telling me that it was already connected. I guess I didn't clean up properly, but the above trick seems to work.
Thanks (and let me know if you know of a better way to do a "robust connection").

@mosquito
Copy link
Owner

mosquito commented Jan 8, 2022

You can peek into the aio-pika code. There is implemented just what you need. See RobustConnection/RobustChannel/RobustQueue/etc...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants