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

PYTHON-5089 Convert test.test_mongos_load_balancing to async #2107

Merged
merged 11 commits into from
Feb 6, 2025

Conversation

sleepyStick
Copy link
Contributor

No description provided.

@sleepyStick
Copy link
Contributor Author

Note: I believe the failing evergreen tests are unrelated to the changes I've made

@sleepyStick sleepyStick requested review from NoahStapp and ShaneHarvey and removed request for NoahStapp January 31, 2025 16:28
@sleepyStick sleepyStick marked this pull request as ready for review January 31, 2025 16:28
@sleepyStick sleepyStick requested a review from NoahStapp January 31, 2025 16:29

@async_client_context.require_connection
@async_client_context.require_no_load_balancer
def asyncSetUpModule():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly there isn't an async version of unittest.setUpModule. I'd just add these decorators to an asyncSetUp method for TestMongosLoadBalancing instead since it's the only test class in this file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah good to know, makes sense

pass


if not _IS_SYNC:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's standardize these checks to if _IS_SYNC for clarity.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay yes, that's what I wanted (and did initially) but for some reason if its if _IS_SYNC first, type-checker assumes both definitions of SimpleOp inherit from threading.Thread and then insist that both implementations adhere to the thread api (in this case join must return a value)
is that preferred? it felt weird to return a value for the sake of it in the async version of SimpleOp simply because its not used at all

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our typing checks do, or the IDE's own highlighting does? Either way, we should have all checks be for _IS_SYNC whenever possible for clarity.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both, our typing checks is what caught my attention first actually


class SimpleOp:
def __init__(self, client):
self.task: asyncio.Task
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
self.task: asyncio.Task
self.task: asyncio.Task = None

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm I don't love that because it'd mess with the type of self.task (specifically it'd have to be Optional[asyncio.Task]) in the interest of not making it optional, I moved the assignment from start() to the init. Does that work? Is that better?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you show what you mean exactly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I thought I committed and pushed HAHA sorry about that actually pushed now)



async def do_simple_op(client, nthreads):
threads = [SimpleOp(client) for _ in range(nthreads)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about using tasks here instead of threads?

Copy link
Contributor Author

@sleepyStick sleepyStick Jan 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i like it / wanted to do it but noticed that it'd result in the sync version of the file to be tasks, would I need to modify synchro to change tasks to threads to get this to work?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd need to have it only do so within test files and with a specific token set to not also change things that happen to be called threads but aren't what we want to synchro.

I'd rather have concurrent executors always be called tasks for consistency rather than have them be called threads in the async code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, its tasks now :)

if not _IS_SYNC:

class SimpleOp:
def __init__(self, client):
self.task: asyncio.Task
self.task = asyncio.create_task(self.run())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the earlier version, sorry for the churn.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope all good, i offered it as an alternative :)


def run(self):
self.client.db.command("ping")
self.passed = True # No exception raised.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we settle on a common pattern for the threading.Thread -> Task conversions? I made some suggestions in #2103.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on the approach in #2094?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I believe if I implement noah's suggestion above we'd be using the same pattern :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(i think my tab wasn't fully refreshed earlier so i'm just seeing Noah's comment right now) but I actually really like that approach!

@sleepyStick sleepyStick requested a review from NoahStapp January 31, 2025 20:12
Copy link
Contributor

@NoahStapp NoahStapp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you refactor this to use ConcurrentRunner added by #2094?

@NoahStapp
Copy link
Contributor

Sorry, I found the same join bug in one of my PRs and that's caused the conflict.

@@ -395,7 +395,7 @@ def __init__(self, **kwargs):
async def start(self):
self.task = create_task(self.run(), name=self.name)

async def join(self, timeout: float | None = 0): # type: ignore[override]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great find on this bug. It's not at all obvious and causes a lot of confusing behavior that's hard to spot.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup 😭 it took about 20 print debug statements and a good nights rest and a whole lot of "this makes NO sense" until i figured it out HAHA but now that I've noticed it, i'm like why didn't i see it sooner!


@client_context.require_connection
@client_context.require_no_load_balancer
def setUpModule():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can keep these to improve performance when skipping this test suite.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved it to the class's setUp because on the async side it'd require setUpModule to be awaited and i couldn't find an easy way to achieve that. I figured it was the only class in this module so it didn't make a difference to just move it into the class. But if you know how i could await this in async, I have no hesitations to bring it back!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh whoops my bad, forgot how the wrappers interact with async. You're right!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good, wasn't sure if I was missing / forgetting what the trick was!

passed.append(True)

if _IS_SYNC:
threads = [threading.Thread(target=f) for _ in range(nthreads)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use ConcurrentRunner for these as well?

@sleepyStick sleepyStick requested a review from NoahStapp February 6, 2025 18:12
Copy link
Contributor

@NoahStapp NoahStapp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work!

@sleepyStick sleepyStick merged commit a1a2109 into mongodb:master Feb 6, 2025
36 of 39 checks passed
@sleepyStick sleepyStick deleted the PYTHON-5089 branch February 6, 2025 18:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants