Skip to content

Investigate on asynchronous interface #49

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

Open
DanielePalaia opened this issue Feb 24, 2025 · 3 comments
Open

Investigate on asynchronous interface #49

DanielePalaia opened this issue Feb 24, 2025 · 3 comments
Labels
enhancement New feature or request

Comments

@DanielePalaia
Copy link
Contributor

Is your feature request related to a problem? Please describe.

At the moment our client is using as wrapper the the qpid-proton client for python: https://github.com/apache/qpid-proton/tree/main/python

which is not supporting asynchronous APIs

The python code has been integrated in our project and can be modified and extended (a possible asyncio integration is possible) but we would prefer not to modify the C layers underneath (both api and implementation).

We can think on a possible python asyncio integration, maybe creating separate class for this like uamqp si currently doing: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/servicebus/azure-servicebus/azure/servicebus/_pyamqp/aio/_sender_async.py

Describe the solution you'd like

Explore possible solutions

Describe alternatives you've considered

No response

Additional context

No response

@DanielePalaia DanielePalaia added the enhancement New feature or request label Feb 24, 2025
@Darsstar
Copy link
Contributor

Darsstar commented Feb 26, 2025

A separate set of classes is perfectly acceptable.

The C layer does not have to change, Python has enough tools to wrap callback based APIs into async/await APIs. (asyncio.get_running_loop().create_future() is one such tool.)

Consumer.run() is an example of a poblematic function since it blocks the thread, and therefor the ascynio event loop. Calling it via asyncio.to_thread() might be enough. It is way to soon for me to say with any confidence, however.

I saw your branch test_asyncio, I recommend adding the following to pyproject.toml and updating to the latest pytest-asyncio:

[tool.pytest.ini_options]
asyncio_mode = "auto"

I personally like that better than pytestmark = pytest.mark.asyncio.

PS. why is python-qpid-proton vendored? I am not against it, but I am curious.

@DanielePalaia
Copy link
Contributor Author

Hi @Darsstar yes please don't take in consideration my branch (it was just to do a few tests with asyncio on this specific project). If you would like to contribute on this task and @Gsantomaggio agrees please assign it to you (so that everyone know if are working on it) and go ahead from scratch

@Gsantomaggio
Copy link
Member

Ok with me. Thank you @Darsstar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants