-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
Race condition getting boto3.client("rds-data") #43
Comments
This fixes issue cloud-utils#43
Thank you for identifying this issue. We'll fix it in your PR after some minor modifications. It's unfortunate that boto3 advises that clients are thread-safe yet allows fatal races in its own client initialization code. Seems like a bug in boto3. Would you be interested in opening a bug in boto3? |
I'm willing to open a bug in boto3-land. I haven't done it nor really gone hunting for any existing bug. I wanted my stuff to work, which I got to! Getting my stuff to work involved me to digging deeply enough into aurora-data-api to be able to point clearly at the problem as it happens here and suggest a fix. |
Um, https://github.com/cloud-utils/aurora-data-api/blob/main/aurora_data_api/__init__.py#L41 does not fix the problem. That gets a new, separate, lock in each instance of |
That lock is a class variable, initialized once on load with the declaration of the class. While it's scoped to the class instead of the module, it is functionally no different. So if it doesn't fix the problem you encountered, then I believe neither would your proposed solution. Can you give it a try and see if you can reproduce the error? |
Ah. You are correct about the class variable. Sorry for my confusion. For what it's worth, I would write it with explicit use of the class variable, like this: if rds_data_client is None:
with AuroraDataAPIClient._client_init_lock: In general (and not relevant here), using |
This bit of code is not thread safe.
The problem here is that getting a boto3 client is not thread safe. Using a single boto3 client is thread safe.
I can hit this issue consistently with multi-threaded use of SQLAlchemy when SQLAlchemy tries to get two database connections concurrently.
Once I figured out what was happening, I realized that I can pass in
rds_data_client
to avoid this race.The problem can (and probably should) be avoided within this driver by assuring that the rds-data client is only gotten once, globally, across multiple instances of
AuroraDataAPIClient
.Here are the three (similar) relevant stack traces (with my code at the top of the stack snipped off):
The text was updated successfully, but these errors were encountered: