-
Notifications
You must be signed in to change notification settings - Fork 1.1k
PYTHON-4725 Async client should use tasks for SDAM instead of threads #1896
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
PYTHON-4725 Async client should use tasks for SDAM instead of threads #1896
Conversation
pymongo/asynchronous/monitor.py
Outdated
if _IS_SYNC: | ||
_shutdown_resources() | ||
else: | ||
asyncio.run(_shutdown_resources()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work because there is already an event loop running, we need something like https://github.com/minrk/asyncio-atexit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, something was funky HAHA thanks for showing me a fix!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would i be allowed to import this and use the package? or should i just take the code that we need and put in on our own code base? thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this at all? What happens if we do nothing for async clients at exit?
Do our SDAM tasks prevent the loop from exiting?
We document that an AsyncMongoClient must always be closed() so I don't believe we need to do anything. If the app leaves the client open, that's a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took it out of async and it seems to be fine so far.
…routine in sync verison
@@ -28,6 +28,99 @@ | |||
_IS_SYNC = True | |||
|
|||
|
|||
class SyncPeriodicExecutor: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should organize the code such that we don't sync this code since it will never be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in move this file out of the async / sync folders right? If so, that makes sense to me :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. We can have one file that has both.
test/asynchronous/__init__.py
Outdated
return | ||
global async_client_context | ||
await async_teardown() | ||
async_client_context = AsyncClientContext() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't work because the old client_context
was already imported by other files so this change won't be reflected there. For example:
>>> import pymongo
>>> from pymongo import ASCENDING
>>> ASCENDING
1
>>> pymongo.ASCENDING = 2
>>> ASCENDING
1
>>> pymongo.ASCENDING
2
Instead we need to mutate the existing ClientContext
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh that makes sense, thanks!
One issue: A test emits an error from the _process_kill_cursors task (I'm not sure if this is expected or not):
Another issue a test teardown times out after blocking for 25 minutes:
I don't see any time outs like this happening on mainline so I think it's related to the changes here. Both happened on execution 1 of this task: |
I created an
AsyncPeriodicExecutor
class because it differs enough from the regularPeriodicExecutor
class -> this resulted in moving upperiodic_executor.py
up to the top level.In the process of working on this ticket, I noticed some bugs in the tests (async tests using
wait_until
instead ofasync_wait_until
) that are now appearing since background tasks are running in the event loop instead of on threads.