some question that belongs on stackoverflow

[nbraun-wolf]

No description provided.

[frederikaalund]

Thanks for opening this issue. 👍 Let me have a look. :)

I know in the advanced example it's using context manager and stuff like this. And the maintainer discourage the direct use of connect and disconnect calls.

Yes, I do. :) It was a design mistake on my part. Use the context manager interface instead.

However, in my current application, I want to use the client globally across different files.

Don't. :) It's an anti-pattern.

I am using it to publish messages inside http handler of a web framework. So I am not sure if a context manager would be feasible for this, and if so how to implement it.

Luckily for you, it is feasible. I assume that you use something like FastAPI. It supports context manager dependencies through dependency injection. This way, you can tie the lifetime of your single asyncio_mqtt.Client instance to the life time of the fastapi.FastAPI application.

Learn to love (async) context managers in python. They may seem like unnecessary boilerplate at first but they are definitely worth it in the long run. Just take my word for it. :)

---

Now to the actual issue at hand here: Reconnection.

The original paho library will just attempt reconnects on its own, once the connection has been lost, and for me as user nothing has to be done. I can keep using the same client I have initialized once. Maybe a publish will fail because the broker is currently not available, but soon after the broker is back the publish will succeed again. From my current tests this doesn't apply to this async client. I can shut down the broker and bring it back up, but the client will afterwards always report that it couldn't publish.

Yes, this is something that really makes paho-mqtt user friendly. Unfortunately, we (asyncio-mqtt) don't support automatic reconnection (yet). It's a trade-off between user friendliness and design complexity. IMHO, it's not worth the design complexity. I want to keep asyncio-mqtt lean—just a small wrapper around paho-mqtt. Otherwise, I don't have the bandwidth to maintain it. Simple as that. :) If someone joins us (asyncio-mqtt) and share the maintenance burden, then we can consider automatic reconnection. 👍

Some of the required changes just on the top of my mind:

• We need to close Publish should not wait for confirmation #48 before we tackle reconnection. Maybe have both an immediate publish and a publish_and_wait call as well.
• Add automatic_reconnection keyword argument to the Client.
• If automatic_reconnection==True, we either use the existing paho infrastructure to do it (if feasible), or, do it ourselves with an internal loop.

If anyone us up for this, feel free to open a PR. 👍

[frederikaalund]

The context manager is tied to the lifecycle of the single request and not to the lifetime of the application. Please correct me if I am wrong.

You're right. I thought it was scoped to the application but it seems that it's scoped to each request.

Currently, I only see options to get proper reconnect behaviour if it's subscribing to something, since those are long-running coroutines which can be awaited.

Please provide an example of how to achieve the desired behaviour with a context manager.

I welcome anyone to make a pull request that adds this example. :)

Your question is about scoping and life time management. In other words, it's a question about how asyncio tasks work in general (and Python scope rules and import system in general). You need to find support for this elsewhere (e.g., stackoverflow.com).

asyncio-mqtt provides a general-purpose context manager interface. That is good enough for any use case. It's up to the user (you) to build on top of that. Yes, that currently includes reconnecting, connection pooling, etc. Whether your framework of choice (e.g., FastAPI) helps you with that or not is outside the scope of asyncio-mqtt.

This issue tracker is for specific bottlenecks/design choices/bugs in asyncio-mqtt that prevents you to build on top of it. I'll gladly review/accept PRs that improves these things. 👍 This issue tracker is not for how python and asyncio works in general. I just don't have the bandwidth to answer general-purpose python/asyncio questions. I wish I had time for that but unfortunately I don't. :) Don't worry, there are other places (stackoverflow) where people seem to have plenty of time to answer your questions. 👍

---

I'll keep this issue open to address the issue of automatic reconnection because I think many people expect that. 👍 Hopefully, someone wants to make a PR for the development and maintenance of this feature. :)

[frederikaalund]

Let's keep it constructive here. 👍

I'll re-open the issue to keep track of the reconnection feature. Again, if anyone searches for this, PRs are welcome. :)