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

Documentation to handle disconnect/reconnect? #57

Open
matutter opened this issue Sep 25, 2019 · 2 comments
Open

Documentation to handle disconnect/reconnect? #57

matutter opened this issue Sep 25, 2019 · 2 comments
Labels
question Further information is requested

Comments

@matutter
Copy link

matutter commented Sep 25, 2019

Is there any documentation or examples on methods to handle disconnect / reconnect scenarios? Specifically I'm interested in typical or suggested patterns or even an explanation of the behavior of basic_send when the server disconnects.

Example: stomp.py has a on_receiver_loop_ended callback but that pattern probably isn't ideal with asyncio.

@mosquito mosquito added the question Further information is requested label Feb 15, 2020
@mosquito
Copy link
Owner

All classes inherited from aiormq.base.Base has a self.closing future.

So you have two options, wait for it in a background task, or use .closing.add_done_callback(callback). It's might be applicable for channels or connections.

@Krolken
Copy link

Krolken commented Mar 11, 2021

Maybe we can bump this issue.

I have some questions on how to handle the case when RabbitMQ goes down.

So I am consuming messages over TCP in one task and sending them over to anotther task to publish on RabbitMQ.

If i turn off RabbitMQ, send a TCP message and do a basic publish the task hangs forever.
When I turn off the RabbitMQ I get a "reader cancelled" debug output, but all errors are supressed so I cannot wait for that exception to reset the connection and start reconnect.

Right now I am solving it with ensuring the connection has a reader and a writer before the publish, but this could still fail.

I also don't get the TimeoutException from publish. This might be due to that in python 3.7 wait_for will still waits for the task to be cancelled (which seems to never happen) before they raise the TimeoutException

Any thoughts on how to make it a bit more robust? I can probably put in a PR but need som directions from maintainer on how they would like to fix it.

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

3 participants